Refactor Configuration implementation to be more consistent.

Previously, accessing subsets of Configuration objects resulted in
callers receiving Map or Property objects back.  This commit makes it
possible for callers to work with Configuration objects in all
instances.

Additionally, encrypted values in Configuration objects can be handled
within a subclass of Configuration using a fluent API rather than being
handled by an outside class.
This is probably a case where we shouldn't care what class it is and just deny null values straight away. As it stands, there's at least one other map which can have null keys which would fail this check and cause problems (TreeMap with no natural ordering and/or a comparitor that accepts nulls). I'm sure there are other maps in the java.util package which can also have null keys; plus we have no way of knowing what other implementations will do.