Refactor GraphService, graph auto-scan and auto-reload.

This pull request is related to #1519. It also contains some other changes:

- Simplify `GraphService` class and eliminate the class hierarchy (`GraphServiceBeanImpl`, `GraphServiceAutoDiscoverImpl`, `GraphServiceFileImpl`, `GraphServiceImpl`...) with a simpler interface and a single default implementation. The responsability of `GraphService` is now simpler, previous capabilities (auto-scan, auto-reload, memory beans...) have been delegated to external classes.
- The GraphService now manage `GraphSource`s, instead of `Graph`s. A `GraphSource` is responsible for ownership, creation and reload of Graph from whatever source (for now: memory, serialized file on disk, on classpath).
- This splits the somehow unrelated auto-scan (automatically scanning for graph under a base directory) and auto-reload features (reloading a graph if the source has been modified).
- The auto-scan and initial startup graph registration is delegated to a `GraphScanner` class, external to the `GraphService`.
- For registering and saving graphs through the existing web-service API, a `GraphSourceFactory` is responsible of creating new `GraphSource` given a routerIds, and saving serialized graph data. This looks a bit convoluted but is necessary for backward compatibility of the graph registration API.

In non pre-evict mode, if a graph load fails, we keep the old version available. When replacing a new graph, the copy should preferably be done in less than 10 seconds (this timeout is parametrable). If the copy takes longuer than 10 seconds, one or more load will fails before succeding, but w/o impacting any client requests. This only "pollutes" the log. For large graphs on production servers, an atomic move with appropriate backup of old data in case of problem is preferable anyway.

In pre-evict mode, user requests are blocked while loading a new graph (this is necessary as we want to remove the old graph before loading the new one to save memory). Currently pre-evict is not parametrable via command line parameters but this could be added quite easily.

Currently there is no way to unregister a graph in "automatic" mode. "auto-scan" only register new graphs available, and "auto-reload" will keep the graph currently in memory if the graph file has been removed. This behavior can be modified if needed. A graph can be unregistered using the web-service API anyway.
I find it confusing to name a variable after the software development pattern its Type employs. I would favor naming it after what it does or is (e.g. configurator).