[Cleanup] Serializer caching is its own concern

[bf4]

Update 2016-03-13

Rebased off of master.

Original Description

I was looking at the caching code and realized that although it is called
from the adapter, it is it's own thing. In fact, if it weren't for
fragment caching, which uses the adapter instance, the caching code could
be used entirely by the serializer!

I wrote this PR in two commits so that the moving down of the CachedSerializer
and FragmentCache classes from the Adapter namespace and the moving to the
ActiveModelSerializers namespace can be more easily seen. I intend to squash
them before merge, but would be happy to do it now.

[bf4]

This is an adapter method since the adapter might want to customize how the two hashes are merged, e.g. see JSON API adapter.

-          non_cached_hash.merge cached_hash
+          root = false if instance_options.include?(:include)
+          core_cached       = cached_hash.first
+          core_non_cached   = non_cached_hash.first
+          no_root_cache     = cached_hash.delete_if { |key, _value| key == core_cached[0] }
+          no_root_non_cache = non_cached_hash.delete_if { |key, _value| key == core_non_cached[0] }
+          cached_resource   = (core_cached[1]) ? core_cached[1].deep_merge(core_non_cached[1]) : core_non_cached[1]
+          hash = (root) ? { root => cached_resource } : cached_resource
+
+          hash.deep_merge no_root_non_cache.deep_merge no_root_cache

[groyoh]

I think using serializer.class here is less typo-prone. A typo on serializer would result in NameError whereas a typo in @cached_serializer would result in nil.

[NullVoxPopuli]

needs rebase :-)