Add db:metadata functions for handling of doc metadata

[Zachary Dean]

@grantmacken yes, the db:link is very similar to the atom media-link-entry.
The saving of the file would need to happen either with the file module, or could be done outside of xqerl in the OS.
The link is just a reference from URI to filename. Upon selecting the linked URI, it is deferenced and the file contents returned as a xs:base64Binary. It can be useful when the files shouldn't be saved in the DB, but rather updated from outside. Within an XQuery context, the file is read a maximum of once, and cached. Since files can change outside xqerl's locking system, this is the only way to keep it deterministic (which it must be).

As for ETags and other content types:
I think I'll add an optional $meta as map(xs:string, xs:string) parameter to db:put that allows saving custom metadata. Also I'll add a db:metadata function that will return said metadata about a given URI. This could then be used to set custom headers (or whatever information about the data).
There could be some values that are always set with binary and text types, such as etag, timestamp. For links, this data will be retrieved/calculated from the file itself.
The timestamp for XML is already in the DB and part of the document key.
This will also allow for saving text as csv, plain, json, or whatever. or XML as text/xml, application/xml, atom+, etc.

I may think about adding the $meta parameter to functions meant to get collections. It could then be used as a filter. Or maybe a custom uri-collection function that can be filtered in this way instead of calling db:meta on every entry.

Originally posted by @zadean in #25 (comment)