Proposal: Describe possible project structure and implications

Initial thoughts around scoping Kubernetes resources to projects and the associated implications.

Intended as a complement to #891, but with more detail on the implementation consequences of project scoping throughout the stack.

Would like to get general agreement on an outline to proceed against to support an initial prototype in next couple weeks.
There are two discussions going on in lines 66 to 90
One is about the user-visible semantics of project-scoped object CRUDing.
The other is about a specific go implementation.

I suggest first summarizing the semantics .. something like:
`When a project scoped object is created or updated, it must be for a project that already exists.
When a project scoped object is listed, blah blah blah.`

Then talk about the specific implementation, i.e. ProjectResourceStorage and delegation.  That can go away when this becomes user documentation.  Also, I have a feeling it may be more controversial.