Remove all extensions from Core

[cholmes]

The major change for rc.1 has been that a majority of the extensions have moved out of the core spec, into their own github organization - https://github.com/stac-extensions/

Everyone has been quite pleased with how this turned out, as there is a nice template repository and it's quite easy to make a new extension and publish it when ready. These are now all independently versioned, and can release at their own schedule. The only small downside is that there is no longer the ability to refer to a 'shortcut' name, like 'sar' - you must refer to the whole schema file (which was always an option before), since its version may change.

We left 4 extensions in the core spec, that do get to use the shortcut names, but are now considering removing them entirely. This would provide a single path for implementors - clients would not have to check shortcuts, see if it's in core, and then treat those differently than the non-core ones.

This is not a huge deal, but it seems overall better to just have one consistent way of doing things. At some point we could play with an alternate way to re-introduce shortcuts in a new mechanism.

But the discussion in https://github.com/stac-extensions/raster/issues/3 raised that the core EO extension may not be as 'stable' as we thought, as the raster band construct seems more general purpose. If eo is not in core then it is easy for it to just issue its own releases and evolve. But if it's in core then we'd need to do core spec releases to change it, and likely would have to jump to STAC 2.0 if we wanted to do any substantive change. But if we move it to an extension then the core can stay stable and small.

Everyone felt that it'd be best to not just treat EO as a one-off, but just switch to every extension living in its own repo. We'd keep the extensions section, and would have a 'stable' section for those who really want to rely on the most solid extensions only.

This is a breaking change between rc.1 and rc.2, as clients will no longer work with the extension shortcuts. So we'll be doing our first official Project Steering Committee vote, to ensure everyone is on board. The logic on this change is that all implementations have to do the same change for beta.2 -> rc.1, and that the release candidate period is one that we expect some flux in. We try hard to limit that to just bug fixes, which is why we want to raise this to the PSC, as it is more than a bug fix.

Let's aim to close this vote by monday morning, so we can try to cut the release at the regular stac meeting. We'll aim to get the PR ready to go, but not merge until the issue is decided here.

@matthewhanson - are you able to make the PR? If not I can probably take it.

[cholmes]

And I am +1 on the change.

[lossyrob]

LGTM +1

[matthewhanson]

+1 and yes I will create the PR