Rewrite frontend of legal document search + add; fixes #1933

This is the frontend half of #1956 to complete #1933.

There are two places in the code where users can add legal documents—from the "Add Content" button on the right, and from the "Quick Add" field in the table of contents. This is intended to replace both, ultimately, but this PR only includes the "Add Content" functionality.

Some of this code is duplicative of the existing legal doc flow. The final PR will make this work net-negative in terms of lines of code, but for now this is mostly additive.

This is a fairly big PR but the work was hard to roll out incrementally since it replaces a feature already there.

The UI looks very similar to before, with changes that are designed to aid readability and bring these results more in line with the presentation of the casebook search results.

Before

After

The most substantive UI change happens after a case is selected. Previously the page would do a full refresh and take them to the edit-resource page without any notification of what occurred (the legal doc was added to their casebook at the end or in the current section).

Now when they select a search result, they are notified about what happened and prompted to make a choice about what to do next:

Full changelist

The new code does not make use of the Vuex store. It does all its rendering and event bus management within the scope of the container, search form, and results components. The round-trip to the store seems to cause a lot of browser instability and may have been a source of the performance bottlenecks @cath9 was experiencing when demoing over Zoom. Since the search information is confined to these parent/child relationships, there's no need to use a store.
This makes use of the new endpoint from #1956 to handle the addition of the legal doc in one HTTP request rather than 2 serial ones.
When querying multiple sources (the default behavior), the existing code runs the queries serially. This runs them in parallel and waits for both to resolve (h/t @matteocargnelutti).
Supports full keyboard navigation, including result selection.
For results without external links (see #1959), omits the hyperlink and external link icon.
Avoids use of backwards-facing shims in favor of markup and APIs that are now solidly browser-native (a function of the time elapsed since this was first written). Specifically:
- Uses fetch() rather than Axios (and since it uses a new API endpoint, it avoids any of the monkeypatching to handle Rails-compatible REST behavior)
- Uses only the native date input rather than adding a shim
- Uses flex rather than tabular layout for results
- Includes only semantic markup (no divs!)
- Uses URLSearchParams rather than a custom function

TODO

There's explicitly no exception handling on the fetch requests right now. They should recover if the backend errors so the UI doesn't freeze, but still report up to Sentry. I'd like to research how best to do this.

There are unit tests for only one component. There should be some coverage for all three. (IMO this work is better suited for unit tests + mocks than Playwright tests, which would require a lot of backend fixtures when the backend is already covered by Python tests.)

I'd like to put this branch up on staging for some human testing before even considering merging, given the size of the PR.

harvard-lil / h2o