Add support for providing configuration to player persistence implementations

[garyttierney]

The current implementation of player loading/saving in Apollo relies on the persistence providers having a no-args constructor, making implementation of persistence providers that rely on external systems troublesome.

For example, a persistence provider that uses a JDBC connection to load data from a SQL database will likely want to pool its connections. To achieve this the implementation would need to share the pool via static state, which makes testing difficult and the code obtuse.

Solutions:

• Bootstrap the server using a fully-fledged Dependency Injection framework (Guice?)
• Extend the PlayerLoader XML reader with support for passing in configuration parameters/other objects.

[Arham4]

I would argue for Dagger 2 over Guice. Compiler auto-generated code (Dagger) will prevail for me over reflections during run-time (Guice), but I probably have a bias because I used jOOQ for SQL querying and loved auto-generated code because of it. I like having compiler-enforced behaviors.