Specify metadata mechanism for Containers, RDFResources, NonRDFResources

Parent issue: #102 - Specify approach for resource meta-data.

We currently have the (highly under-specified) .meta mechanism. As part of the 1.0 spec, we should:

• Re-confirm the use of describedBy link relation header, to point to the .meta file (if we're going to continue using that mechanism)
• Specify semantics of .meta for Containers. Current behavior/spec: a PATCH to an ldp:Container results in the triples going straight to the container's .meta resource. A GET to a container transparently includes the triples from the .meta resource.
• Clarify whether the presence of a .meta resource in a Container counts towards that container being empty or non-empty (which affects DELETE semantics). Currently: .meta is ignored / counts as empty.
• (n/a - no globbing going forward) If globbing still exists, clarify the semantics of .meta with respect to results of a glob operation.
• Specify the semantics of .meta for NonRDFResources. Currently, .meta is the recommended mechanism for adding metadata / RDF triples to arbitrary non-RDF resources. Original issue: https://github.com/solid/solid-spec/issues/197
• Specify the semantics of .meta for RDFResources. It is unclear whether RDF Resources are a) allowed to have their own .meta resources, or b) whether that's recommended behavior. There are some arguments that RDFResource are their own metadata (see also the approach taken by the Hydra community). But arguments can also be made to the contrary (especially when it comes to server-protected metadata, a separate topic.)
• Clarify the permission/.acl semantics of .meta resources. Currently: Unclear, but I believe a .meta resource can have its own .meta.acl resource, but defaults to the same permissions as the resource that it describes? (See solid/#130 - ACL for .meta resources)
• Clarify the lifecycle of the .meta resource (similar to issue https://github.com/solid/specification/issues/58). See also issue solid-spec/#168 - How to delete meta file?
• Specify how .meta resources get serialized/exported to the filesystem, with regards to File system data portability
• Differentiate user-writeable metadata from Server-protected metadata