This replaces the ConfigurationSection-based getCustomData() method.

The metadata store will only accept a new PersistentMetadataValue
class, which encapsulates and hopefully clarifies the notion that only
"persistable" data can be stored here. This includes Lists, Maps, most
basic types, and ConfigurationSerializable objects.

This provides an efficient mechanism for the common use case of wanting
to check for the presence of a specific metadata key without unpacking
all of the metadata.

I have to admit I'm not sure what specific use cases will result in the
base ItemStack methods getting called, but this is generally the
correct thing to do, and let descending classes override for
optimization purposes.

I think this is a good fit here as an extension to Metadatable, the
more common use case is for a Plugin to want to retrieve its own data.

There is no longer an efficient way to perform this check, and I don't
believe there was a valid use case for its existence in the API in the
first place.

If a Plugin wants to interrogate for data, it should be doing so with a
specific key.

Extend MetadataValueAdapter directly for performance, and remove all
the variant constructor types. They were meant to serve as a
compile-time suggestion for what types are ok, but in practice it feels
cluttered.

Restore type-specific constructors, and add asList and asMap accessors.
I did not add array accessors.