WIP: EO Band references proposal

[philvarner]

This PR contains examples for a proposal to rework how EO Bands are defined and referenced from Assets, and to act as a facilitator for discussion.

There are three common use cases for Bands:

1. I have a static Catalog, and define the Bands in the Catalog and reference this single definition from Assets.
2. I have an API returning an Item with Assets that share no or few bands, and I want to put the band definition directly in the Asset to avoid indirection.
3. I have a static Catalog or API with Items with Assets that share more than a few bands, and want to define them once in the Item and reference each Band from multiple Assets.

The design constraints around bands are thus:

1. Bands may defined in an Item or its parent Collection
2. Assets that share bands should be able to each reference a single Band definition
3. Many Items will contain Assets that share no bands (e.g, Landsat 8 PDS), so defining Bands separately from the Asset they use them an unnecessary level of indirection.
4. Referencing Bands by array index is prone to implementation errors, and fragile in the the face of reordering Band definitions.
5. Semantics for when Bands are defined in the Item and in the Collection are not clearly defined (I would assume Item definition would take precedence, but this is not stated explicitly anywhere)

Overall, I fell that this proposed specification is a good balance between static catalogs that will typically define bands in the Catalog and API result Items that will need to be self-contained and can therefore have the band definitions within the Asset.

PR Checklist:

• This PR has no breaking changes.
• I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
• API only: I have run npm run generate-all. to update the generated OpenAPI files.

[m-mohr]

An issue worth reading on the history of bands in STAC: #142