[1037616] Pull calls to find current availability out of the processing loop
Optimization work based on BZ-supplied patch. For a batch of Availabilities
being processed, pull latest availabilities for the resources  in one DB
round trip as opposed to once for each resource.  Still beiong careful to
repair issues when no, or multiple, latest entries are found.
[1038256] Windows 2008 - Invalid agent service after upgrade (on remote agent machine)
This problem resulted from the work in Bug 1016609, when we introduced
the use of RHQ_JAVA_EXE_FILE_PATH and deprecated the use of
RHQ_AGENT_JAVA_EXE_FILE_PATH (among several simplifications of our
env properties).  The issue with that change was the fact that existing
windows agent services (remote agents, not handled by rhqctl) included
set.RHQ_AGENT_JAVA_EXE_FILE_PATH in the service "path to executable", for
use by the service wrapper.  But the new rhq-agent-wrapper.conf expected
RHQ_JAVA_EXE_FILE_PATH to be set when formulating its command string.

This was only an issue for existing agents that would be auto-upgraded. Agent
auto-upgrade does not update the existing service, it only restarts it after
the agent update. So, the "path to executable" remains unchanged and therefore
passes only the legacy property.  Note that auto-upgrade does the right thing,
it should *not* replace the service in order to update its definition. Doing
this could lose the RUN_AS password, which may have been set interactively
when the agent was initially installed.

The solution should be good, the rhq-agent-wrapper.conf has been reverted to
use RHQ_AGENT_JAVA_EXE_FILE_PATH.  We still completely support the
new RHQ env properties, like RHQ_JAVA_EXE_FILE_PATH, but will supply
the legacy property at service install time.  That gives up backward
compatibility while keeping the use of  RHQ_AGENT_JAVA_EXE_FILE_PATH
internal.
[1037616] Pull calls to find current availability out of the processing loop
Part 2 - batch the pull of ResourceAvailability records that need to
be updated due to changed availability. Pull only the necessary records.
[BZ 1038067] - Resource Summary/Activity shows summary of disabled
metrics - fixing the issue for resource groups (Autogroups and
compatible ones).

Also doing some refactoring, because the same code was in the portlet
for resource and for group, so I moved the common functionality to the
group portled and resource portlet overrides the different parts. What
would be even better is to introduce a common abstract class in the new
package
org.rhq.coregui.client.dashboard.portlets.common (the same way it is
done in the org.rhq.coregui.client.inventory.common package). However,
all the portlets follow this pattern (ResourcePortlet extends
GroupPortles), so it would be inconsistent.

After the refactoring, the code is more flat because the callback hell is
not so evil when using own methods for each callback. The toll for it is
the number of arguments that has to be passed to those methods
representing the state that is needed inside the method.