Make STAC Browser more lightweight

[m-mohr]

An intial request to the Planed Disaster Catalog requires to load a total of 3,6MB (uncompressed) / 0.77KB (compressed) in STAC Browser 1.0:

• HTML: Neglectable
• CSS: 0.27 / 0.03 MB (much of this is cached in subsequent calls)
• JS: 3,21 / 0.67 MB (much of this is cached in subsequent calls)
• JSON: 10 / 0.02 MB (subsequent calls, e.g. for items, are larger as more parts of the catalog need to be loaded, e.g. JSON Schemas, parent catalogs, ...)
• Imagery: Not looking into it, can't change it

Even on a 4G connection the initial load time is multiple seconds, don't even try 3G...

I'd like to reduce this as far as possible. With STAC Index I've also realized that the bundle size is an issue for the crawlers.

[m-mohr]

An overview over the bundle size after the vue-cli migration:

It clearly shows we can gain quite a bit by the following means:

• [x] Try to reduce bootstrap-vue. Consolidate Icon use (we also include FontAwesome, i.e. have two icon sets loaded, which seems unnecessary)
• [ ] Load vue and/or leaflet from CDN?
• [x] Remove ajv and don't validate Items/Catalogs up-front (would also remove requirement to load JSON Schemas) - I'm actually not sure why this is a thing in STAC Browser. We have validation tools for that.
• [x] Lazy load components (e.g. Catalog/Item, Vue Multiselect)
• [x] Check other dependencies regarding usefulness

[m-mohr]

Thie vue-cli migration, optimizing the bootstrap-vue dependency and lazy loading components, I'm currently down to a total of 1,15MB (uncompressed) / 0.37KB (compressed), which is mostly due to decreasing the JS sizes to 0.85 MB / 0.26 MB and smart/async bundling. It still loads additional resources, but that's as part of the pre-fetching of the browser and doesn't influnce the initial load time. So loading time has been more than halved.

[m-mohr]

Idea: Don't bundle the heavy stac-layer dependencies (proj) when a tile server is used.

[m-mohr]

STAC Browser v3 is roughly at the same initial page load size as v2, but with additional functionality so this is not overly concerning, I'd say.

A potential improvement would likely to only load the multihashes library when it is really needed. Right now it is always loaded, but rarely used.