Limit CNAB references throughout documentation

[carolynvs]

It's a bit confusing right now how we talk about CNAB, the spec, how porter maps back to it, etc in our docs right now. Because we can't make assumptions about what people know, and if people are coming to a page because they want to know about a porter feature or because they want to know about how porter is conforming to the spec.

I spoke with @jeremyrickard and we agreed on how to organize the docs a bit:

• Add a page explaining CNAB and how porter uses it
• Add a page explaining how the manifest maps to a bundle.json, where we conform to the spec and where we have unique features/data
• On each page, call out interesting CNAB tidbits in a subsection titled CNAB.
• Don't start any doc with references to CNAB, or assume that the reader already knows what it is. Assume that each porter doc (and the reader) is there for the porter feature first.

[carolynvs]

New plan: We still need 1 page that explains CNAB, but otherwise unless its clearly relevant we no longer want to try to point out how everything relates back to CNAB. At this point it's just an implementation detail.

[carolynvs]

I still want to do a sweep so that we don't use mixed terminology for things like invocation images (cnab) vs bundle image (porter).