Allow non-rdf resources as auxiliary resources

As per spec, currently auxiliary resources can be just LDP-RSs.

Auxiliary resources are represented as RDF documents [RDF11-CONCEPTS]. HTTP interactions on auxiliary resources are subject to the requirements as per Reading and Writing Resources.

There are many use cases where NRs to be exposed as auxiliary resource, tightly tied to subject resource's acls/life-cycle.

following are some use-cases, where custom solid implementations may want such auxiliary resources.

1. For a given image resource say <a.png>, may be of very high resolution, a custom solid server can auto-generate a thumbnail auxiliary resource <a.png.thumb.png>.
2. A digital-humanities oriented or any other solid-server may want to provide iiif-image api for every subject image resource, with authz & lifetime tightly linked to subject resource. For a given image <a.png>, a iiif-image api, provides an info resource like <a.png.iiif/info.json>, and dynamic resources with format <a.png.iiif/$region/$size/$rotation/$quality.$format> such as <a.png.iiif/0,0,10,100/256,256/0/grey.jpg>. A solid server can easily implement such api resources as auxiliary resources, with desired properties of auth, lifetype binded to subject image resource. And for an auxiliary resource, iri's slash semantics need not be those of solid resources.
3. One may want to read certain xpath of an xml subject resource, like a section in TEI-document.
4. Any of such derived NR resources, like a pdf-page, a file in an archive, etc. can use this pattern of auxiliary resources. Thus if certain domains require preferential treatment to certain NR types, with support of standard apis for them, this pattern will achieve it with little disturbance, and architectural simplicity, with goodies of solid's authz, crud, etc.

No file, test, or entry point is identified in the issue. Start by reviewing the auxiliary-resource requirements and the cited RDF and HTTP constraints; done means the specification clearly determines whether and how non-RDF auxiliary resources are permitted, including their semantics and relationship to the subject resource's authorization and lifecycle.