Cleaner slug generation through conventions

[mojodna]

Conventions:

1. all catalogs are named catalog.json
2. all collections are named collection.json
3. catalogs are always distinct from collections
4. all items are named <id>.json
5. catalogs/collections are nested 1 level beneath their parent

Unfortunately, these conventions fail to hold IRL. This is particularly problematic because there's no other way to determine what the source filename is (or path, in some cases).

CBERS is a very consistent catalog, but its collections (MUX, AWFI, PAN10M, PAN5M) double as 2nd-level catalogs (3).

The root sample Planet catalog doubles as a collection (3).

The Landsat catalog mostly works, although items are 2 levels deep and named as <timestamp>/<id>.json (4) and the timestamp throws things off.

In other words, this approach doesn't work without some retooling of published catalogs (and I'm not clear that there's a path to doing this right, given the ambiguity of resolving filenames).

/cc @cholmes

[fredliporace]

@mojodna CBERS previous static STAC implementation had only catalogs down the 'main' tree and collections definitions in other, separated tree. When upgrading to 0.7 I decided to use a single tree and place collections and catalogs in the same tree.

The current version of the best practices document states:

Collections that are distinct from catalogs should be named collection.json.

I originally understood that as simply Collections should be named collection.json but I now see that this also defines the concept of collections that are distinct from catalogs and this is not clear to me. Every collection is a catalog so the only properties that make them distinct is the presence of collection only fields such as extent.

[lossyrob]

Captured the goal of this work in #46.