Bug 1030063 - Clean up plugin update to work synchronously

Make a pause between plugin update attempts
Comment out Query Cache resource type (perf issue)

For the RHQ Server resource only, 2000+ Query cache resources are inventoried.

The resource type will be commented out until we find a proper solution.
[1037616] Pull calls to find current availability out of the processing loop
A fix in the new impl to handle multiple  updates for the same resource in
the same report.  In general an avail report should only have one update for
one resource, but the potential for building up reports looms in the
future, and we do have this scenario in test code.
irc-bot: fixing the !support command
Intern the strings in the KeyType, as they tend to contain the same things over and over again.
Add some more aliases for Jean-Frederic
BZ 1039107 - Allow to limit alert definitions display by resource id.
Improve description
BZ 961000 - Allow to get and update metric definitions.
Bump the version of remoting
BZ 1037855 - related to the fix for BZ 971556 - we can remove the old async avail infrastructure in plugin container since all resources now do resource async avail
BZ 1037855 - related to the fix for BZ 971556 - don't cache the thread pool in teh avail proxy because this screws up in the arquillian  test framework due to restarts of the PC
this has a good side effect though - it shrinks the size of the proxy, which is good as it lowers the PC footprint
BZ 1037855 - related to the fix for BZ 971556 - fix test
BZ 1039664 - log warning if jon agent rpm is detected
add debug logging
add support in foreach for paging over criteria query results

This is basically a port of the code in CriteriaQuery.java
[998945] Too many statement timeout exceptions in server log
[999165] Frequent statement timeouts while updating availabilities
I did a visual inspection of code looking for things that may
contribute to the slow updates and/or timeouts reported in these BZs. In
general the updates for availReports (infrequent but can spike in
certain scenarios, 1 per avail report) and availPing
(frequent, 1 per minute per agent) should be very fast and not in
themselves be an issue. Slowness in these queries is likely caused by the
Agent table being locked by some other longer running transaction.
Everything looked pretty clean with one exception. When backfilling an agent
due to an agent shutdown or suspect job detection, it looked like we
may have locked th agent table for the duration of the backfilling, which
can be a fairly large operation for a big agent inventory.  I'm not sure
this is the problem, but this commit should allevaite the Agent table
locking while the backfilling is performed.

Also:
- move some inline JPA updates on the Agent to be NamedQuery in the Agent
  entity.  No need to build those every time we update an agent ping time.
BZ 1037855 - related to the fix for BZ 971556 - the last commit for this BZ caused the api check to fail.
putting back the obsolete, but public, constants and marking them as deprecated.
 BZ 1039664 - one more udpate to logged warning to refer to documentation.
fixing bugs in foreach with criteria query