Tracking: Alerts list improvements

Some followups from #3320 related to fleshing out the alert list view. This may break out into a few directly addressable issues (some grouped together, even).

• Componentize similarities with the audit logs page. The gist here is that these are both event lists, so we ought to have component structure to share the table style, pagination, virtualization, special side modal, etc.
• Time filtering for the alerts page. This could arguably be handled in tandem with the audit logs page refactoring!
• Alert class filtering for the alerts page. This one is distinct from the audit log refactor, but somewhat related (and should probably occur serially with that refactor, though the order shouldn't be important).
• Class version may need some explanation. We may not take action here; people who need to care about the class version will likely have a much easier time understanding what it means. But noting the concern.

Start with the alerts list view and the audit logs page, then compare their table, pagination, virtualization, and side-modal behavior. Break the checklist into separate addressable changes for shared components, time filtering, and alert class filtering; treat the class-version explanation as an open decision. Done should be defined separately for each accepted item.