Add initial drafts of high-level design docs

[lukewagner]

Following the proposed next steps for the component model, the component-model repo has (finally) been created and this PR adds docs containing the high-level goals, use cases, and design choices that were presented in the April 27th presentation. In the meantime, we've gotten a bunch more feedback, so the docs reflect an improved understanding of the goals and use cases since April.

The READMEs in this PR explain the repo structure and how the placeholder directories will be filled in by the module-linking and interface-types proposal repos (which I'll soon be rebasing onto this repo from the core spec repo, as previously presented).

[dcodeIO]

It has been mentioned insistently during foregoing discussions that JS needs a separate JS-API mechanism due to its inherent semantic mismatch and is not covered by Interface Types. Is this still the plan, say will there be another layered proposal under the Component Model umbrella to guarantee that integration with JS and between JS-like languages is reliable, or what's suddenly going on here?

[lukewagner]

As already described in the interface types explainer, the idea is to extend the existing JS API spec in-place to map to and from JS values and the interface types defined by the component model.

[dcodeIO]

The interface types explainer is horribly outdated, as you said yourself. It does not mirror anything discussed recently, and now conveniently saying that it would while skipping over all the contrary claims made to win the polls is dishonest.

[dschuff]

@dcodeIO if you want to claim that the current design doesn't meet the design goals (or suggest different design goals), then you can do that. I agree that the interface types explainer could use an update to cover new developments (and it seems fine to ask about what has changed). But these attacks are not acceptable (and in any case are only going to make it harder/impossible to actually engage productively).

[lukewagner]

Alright, well that's enough time for initial feedback. As always with these types of initial PRs, we can iterate on these documents by filing issues and PRs.