Add three new WMI memory metrics for measuring memory paging activity on Windows systems
Add WMI disk read/write, queue length and busy/idle statistics for gathering physical disk load metrics on Windows systems
Add win32_OS WMI data collection class and specific metric to get the total amount of memory visible to Windows
add WMI memory hard faults graph
Add graphs for WMI physical disk transfer rates and correct description and variable name for AvgDiskSecPerTransfer WMI metric
Add WMI physical disk current and average queue length graph
Add graph for WMI physical disk busy and idle time percentages
Add graph for WMI total physical memory
Normalized XML format
NMS-6822: Add WMI support for Paging-Disk I/O-Total Memory

- Merged graph definitions for physical disks from 3 in 1 file
- Merged graph definitions for memory from 2 in 1 file
- Renamed from graph defintion file name to fit better in current name schema
Merge pull request #188 from indigo423/NMS-6822-Add-WMI-support-for-paging-disk-I/O-total-memory

NMS-6822: Add WMI support for Paging-Disk I/O-Total Memory
New Feature: Managing Foreign-Source Repository Strategy

Adding required insfrastructure to select requisition strategy.

A factory class has been created in order to dynamically select the
strategy used to manage requisition based on the value of a system
property called org.opennms.provisiond.repositoryImplementation,
declared on opennms.properties. The default value is file (the currently
used strategy).

Available strategies for Production:
- file (default)
- fastFile (recommended for fastest response, at expense of memory resources)

Available experimental strategies:

- fused
- fastFused
- queueing
- fastQueueing
- caching
- fastCaching

The "fast" version means use the implementations for "fastFile" in
conjunction with ether fused, queueing or caching.

The default qualifier (i.e. "deployed", "pending") for the
ForeignSourceRepository interface are going to use the factory
to obtain the configured strategy.

The DirectoryWatcher class (used by the "fastFile" strategy) is going to
create and maintain a tread for the directory to watch using Java7's
directory watcher feature. The reason for the thread is because and
infinite loop is required to wait for file changes.

Tests:

Tested on a live OpenNMS with more than 500 requisitions and more than
10000 nodes in total. The response time of the Requisitions ReST API is
almost instantaneously. Of course a cache of the requisitions is kept on
memory in order to accelerate the response time.
fix some warnings and logging