Basic metadata/management via JMS

Possibility for metadata in JMS API. Ex. retrieving Queue depth.
Although providers will probably not be able to supply real-time accurate readings, it can be very handy to read out the current depth even if not 100% accurate.
Currently the only way is to browse a queue and count messages (or use provider specific commands).
Other suggestions are: max queue depth, max queue message size and so forth

Management like moving data between objects or deleting messages in one time.
The latter one has currently be accomplished by doing (destructive) reads which is of course not not performant.
(alternatives are provider custom commands, which we would like to avoid for very basic management things like described)
#### Affected Versions
[2.0]

Start by reviewing the JMS API's existing queue-browsing operations and the provider-specific commands the issue aims to avoid. Define the scope and semantics for queue depth, limits, message-size metadata, moving data, and deleting messages, including how inaccurate readings and provider capability differences are handled.

Written by the indexing model from the issue text.