Refactor Data Table Component

[ejmg]

Summary

The current data table implementation either needs to be cleaned up so that it can be used across different types of views for enumerated results and search queries or separate implementations should be broken out between use cases.

Description

Relevant to all features that enumerate any kind of list/search results (ie #7, #8, #9, #10) is the fact that the current data table component is still semi-coupled to specific assumptions of what kind of data will populate it (block and transaction events).

A previous refactoring helped improve this for pagination, particularly so it played nicely with NextJS's server components, but the resulted in two different components (one paginated, one not) and relies heavily on the suggestion of shadcn-ui's example implementation.

Outline

I see this going down one of two ways:

1. One data table to rule them all
2. ~Breakout two data table components to be split between the categories of "Search Results" and generic "enumerated results"~

~I don't see why option 2 would be necessary but it's an easy exit where building out a clean abstraction turns into a headache that is better handled later (or never!).~ Generic implementation is done.

Specific improvements & Rationales

• [x] refactor data table into generic component
• [ ] user table options
  • [ ] sorting by row properties
  • row date or whether the element has an associated event/attribute like a Transaction or Client ID, etc
  • [ ] pagination options
  • paginate by 10 or 20, etc
  • ability to skip pages
• [ ] Styled to handle a reasonable range of columns that will be used by the populating data
  • related to this is the issue of ensuring consistent stylings and variants
  • [ ] Handle "exceptions" like empty blocks
  • [ ] Refine the ability to inline interactive sub-components like buttons, the ability to expand/shrink a row element
  • [ ] I'm sure there is more that I'm not thinking of right now...

This will be an iterative thing. I doubt this will be settled as a one off, especially with respect to balancing other needs. This issue is a good start for enumerating some improvements, however.

[ejmg]

For MVP3, this issue is "secondary" but high value, IMO. Adding some level of granularity to paginated tables–even if it's only the ability to change total # of rows displayed per page and skipping pages–would be a big improvement to anyone using the client to inspect data living on Penumbra.