Make PublicFile.content more flexible than CID<IPFSUnixFSFile>

[fabricedesre]

This was discussed in #18 (comment) but it's not reflected in the spec. The MetaData field looks flexible enough but that is not matched by the content itself. I've started to look at mapping Capyloon's vfs resources to wnfs and with the current spec things will be quite ugly and/or inefficient.

I would need for content to be something like CBOR<Record<string, CID>> : being able to point to each resource variant by name. I'm not sure how that would fit with the private filesystem where the expectation will be to encrypt not just content but also the referenced CIDs.

[matheus23]

I've discussed this with Fabrice in discord, and I actually think that his use cases may be better served by putting more files into a file's metadata.
We should add dedicated support for reading "external" data out of metadata though, so I've added an issue to track that: #50