FLUID-5542: Queued DataSource

Added a Queued DataSource that can combined with different requestQueues to synchronize, throttle, and debounce requests to a DataSource.

http://issues.fluidproject.org/browse/FLUID-5542

This is an extension of the work started in https://github.com/fluid-project/metadata/pull/43
If we keep it at all - we should make sure that we only implement functions or components where we immediately have a use case amongst ourselves or our partners. I think we currently have two immediate use cases on the table - i) limiting write requests to a source of persistence that may self-conflict (e.g. Couch/Pouch), and ii) limiting read requests which are issued to produce a responsive autocomplete API. We shouldn't implement more queue variants than we can demonstrate an immediate use case for, or else we may end up implementing "white elephants" that don't end up with uses. If you can produce a user with a use case for the "throttle" variant, you can consult them for what semantic they want - otherwise we should most likely drop it. I was only reflecting in the comment that the semantic "didn't seem likely to be useful" - but the acid test for this is finding a user to whom it is useful :)