[LIVEOAK-42] Support automagical configuration for resources

Creation of @Configurable and @ConfigProperty to represent whether a Resource contains configuration for reading/updating and which fields are part of automatic configuration handling.

Resource now has a default configuration() method which returns null if the Resource is not annotated with @Configurable. If it is annotated, then we return a ConfigResource that can handle all @ConfigProperty fields for reading/updating.

If a Resource wishes to handle configuration in a non 1:1 mapping of config to field, then they can extend ConfigResource to provide what is needed. It is also possible to mix these modes by annotating some fields with @ConfigProperty and calling super.readConfigProperties() to read them using automatic means, and handle other config directly in implementation.
[LIVEOAK-42] Support automagical configuration of resources

Removed a default string from ConfigProperty.msg(), as ConfigResource can provide a more meaningful default message
[LIVEOAK-42] Support automagical configuration of resources

Remove requirement that RootResource must be annotated with @Configurable if it's not using automagic configuration read/update
[LIVEOAK-42] Support automagical configuration for resources

Add support for a converter to allow conversion to/from the JSON value and an actual object, instead of just a String.
LIVEOAK-3: add in mongo referencing support.
Add an invalid request response for responders to send more types of error messages to clients.
Merge pull request #45 from mwringe/LIVEOAK-3

LIVEOAK-3: add in mongo referencing support.
LIVEOAK-3: remove un-needed dependency on the container which should not have been committed
Merge pull request #46 from mwringe/LIVEOAK-3

LIVEOAK-3: remove un-needed dependency on the container which should not...
* Refactor out a lot of interfaces to SPI from implementations in container.
* Prevent Container from being a catch-all of components
* Use MSC to wire up dependencies between components
* Use MSC to handle more complex lifecycle of Resources
  - instantiate, configure, initialize, register
* Break resource-configuration into a separate file per root-resource
* Allow for ;config updates to reflect back into the underlying file.
* Provide top-level LiveOakSystem providing the basic interfaces used
  by other pieces.  This includes servers, connectors, deployers
  and the container itself.
* Ensure resource-factory registration is concurrently-safe.
* Add DirectConnector to ResourceContext and initialization.
Be concurrent in container resource registration.
Add resources for:

	system
	system/properties
	system/servers
	system/servers/*

* Add a default sub-optimal readMember() that leverages readMembers().
* Comment out test reliant on a class that disappeared.
* Replace DirectConnector with a Client
* Replace Netty's EmbeddedChannel with a real server
  and client, which happen to use the local, in-vm transport.
  (local transport does *not* serialize to bytes)
* Refactor client/server bits to a common/ module
[LIVEOAK-53] Support advanced mapping for automagic configuration

 - Shifted all config SPI bits into a separate package
 - Added @ConfigMapping and @ConfigMappingExporter to handle mapping multiple configuration values into a single object
 - Refactored naming on ConfigPropertyConverter interface methods
* Root is no longer configurable, comment-out test.
* Delete any files that accumulate under target/etc/resources
[LIVEOAK-53] Support advanced mapping for automagic configuration

Switch Resources to use automagic means of configuring them, where appropriate.
 - Remove unneeded implementation of ConfigResource
Checkpoint interceptor work.
* Fix client concurrency issue demonstrated by Stian's test.
* Partially, a block resource should be marked blocking, but
  even non-blocking resources weren't handled completely correctly
  which has been rectified.
* Move local-client thread-handling to the server-side of the local pipe.
Clean up @ConfigMapping so that it is set on the import method instead of a field, meaning that we don't need to specify an import method anymore