Ldap Tests enabled by UnboundID Ldap Server

Deals with https://github.com/Jasig/cas/issues/660

This pull enables ldap tests to execute against an in-memory ldap server backed by UnboundID. The server is first initialized with a common schema, and some CAS-specific objectclasses are registered. Sample LDIF data is then imported into server which primarily drives the tests. The server is restarted per each test class.

I have had to haul the existing ldap tests to somewhat get them functional with unboundid. Hopefully, the presented structure allows one to easily add/remove tests and to observe CAS-specific behavior, with less focus and attention on ldaptive config itself. Most beans are condensed into a single context file that is shared across test classes. 

The sample data that is imported is mostly designed to get tests working, again with focus on CAS functionality while allowing (and assuming) that ldaptive would handle directory-specific changes, configuration and various schemas. 

Probably, the one class that is most impacted by this pull is the ldap-based service registry that is also tested more heavily than others, in view of the recent changes that were made to the CAS service model. There are small changes here and there, but  the most significant one is probably the addition of the objectclass "top" to the ldap entry that contains the CAS service. 

I'll try to highlight other changes as well throughout the pull.
So, this also relates to the other question of why "a service component is serializable". 

Our service model right now contains complex object types which need to be stored into ldap as a whole, rather than individual bits and pieces (as that would be both painful and impractical). So the idea was that we get the whole object serialized into a field and then back out. 

While this implements binary serialization, there was also the suggestion of having these in ldap as JSON character data, which would be somewhat readable and less prone to other issues. 

Right now, we create fields in ldap for lets say "getUsernameAttributeProvider" that gets the entire instance (and everything it carries inside it) serialized as a byte[] and puts it into the field. This is the deserialized on the way back out so the object is constructed in its entirety again. I plan to tackle this next to move away from byte[] and use JSON as the serialization strategy here.