VEDA UI components integration

During our team week eoAPI hacking session, @abarciauskas-bgse @oliverroick and I had a chance to sit down and do a bit of high level thinking about how the work being done on the `stac-explorer` UI can best be generalized for use with other similar projects, most notably [veda-ui](https://github.com/NASA-IMPACT/veda-ui). A lot of the discussion was based around improving my [ideas for STAC API driven self-configuring components](https://github.com/developmentseed/ds-business/issues/1270#issuecomment-1007538947). @oliverroick made [the excellent point](https://github.com/developmentseed/eoAPI/issues/97#issuecomment-1649201273) that we don't want to enforce component design and structure on developers and we should instead be focusing on only a library to handle

1. STAC API request construction and response management.
2. STAC API response -> state/context management and standardized props propagation.

This way developers have all of the hard, drudgery work of interacting with the STAC API handled for them and they only need to worry about designing a great UX that can handle standardized props.

@mmcfarland has already done the bulk of the heavy lifting STAC API typing, query generation and titiler-pgstac mosaic integration but [this work](https://github.com/microsoft/PlanetaryComputerDataCatalog/tree/develop/src/pages/Explore/utils/hooks) is unfortunately deeply embedded in the `PlanetaryComputerDataCatalog` codebase. To continue building out `stac-explorer` in a way that will also be usable for the `veda-ui` we need to restructure this code and move it into a standalone package. I think we can do this in the `stac-explorer` repo in the near term. I'll let @oliverroick correct me here when I use the incorrect terminology, but we discussed a few design goals to guide this work

1. Move as much application/component configuration as possible into STAC structures at the `Collection` or `Catalog` level (this should work with both static STAC documents and API served STAC endpoints). This makes the library much more usable to the wider community who is already using STAC rather than forcing them to build custom configuration at the dataset level as we currently do with the [veda-ui codebase](https://github.com/NASA-IMPACT/veda-ui/blob/main/docs/development/ARCHITECTURE.md#configuration).
2. Simplify API data fetching and caching by using a standard library like [tanstack/query](https://github.com/TanStack/query).
3. Provide examples of using the centralized STAC API state via `useContext` and `useReducer` with sample components.
4. Provide examples of using the centralized STAC API state with [react-map-gl](https://github.com/visgl/react-map-gl) components with the [controlled](https://github.com/visgl/react-map-gl/blob/master/docs/get-started/state-management.md#controlled-map) approach with a footprints and mosaic tiling [sources](https://github.com/visgl/react-map-gl/blob/master/docs/get-started/adding-custom-data.md#native-mapbox-layers) configured by standardized props defined in the library.

This was gist of most of the conversation. We also discussed how we can make these abstractions easily usable across other UI projects. It will be great to get feedback from folks working on the `veda-ui` restructure so that we can make this API request/state management library an easy drop in for STAC API and Titiler interactions if they would like to use it.