Fix several build issues with the flyweight::cache type

flyweight::cache tests for the 'ordered' style are now passing
Modify cache to follow a new style (details in commit message)

Update CMakeLists.txt to use generator expressions for compiler options.
This makes the IF(OPTION) set ENDIF setup a heck of a lot more readable.

The cache has been changed to perform the following:

A type T, a KeyExtractor, and an Allocator are provided to the cache.
In the event that a user desires a key-value system for storing the
items, the KeyExtractor must be swapped out from the default
flyweight::extractor<T> type.

By default, the cache will simply return a shared_ptr<T const> to the
'key' stored within the unordered_map. This works, because not even a
'resize' would cause the cache to invalidate references.

Otherwise, a reference_wrapper<T const> or a T const (whichever is
smaller) is used as the key. The type returned by the KeyExtractor call
operator must differ from type T for this to take effect.

The allocator is rebound as necessary for different allocations.

As of right now, the key-value system has not yet been tested, but will
be shortly. This new approach fixed the issue of selecting a different
container and a whole other host of issues (such as removing the
weak_ptr to the object when it has gone out of scope entirely).

The flyweight::object will be implemented shortly as well.
Fix key-value flyweight::caches not compiling correctly.

Also, for the first time in my life, I've found a valid, safe, and
correct use of a const_cast. After MANY MANY hours of thinking on it
(though this thinking is not reflected by the commit times :P), I've
come to the conclusion that a pointer to a T const, where the T has
already been destructed, is ok to be const_cast away, when the original
pointer to a non-const T was allocated by allocator_traits. You can
check this because an allocator_traits cannot be instantiated with an
allocator that allocates T consts. It is, in fact, undefined. As such, a
const_cast is the only way to then safely deallocate the previously
mutably allocated pointer.

A huge comment on this behavior has been left in the code for others who
may happen to peruse and freak out because 'oh my god, a const_cast was
used'.