Mutable drops should fallback to their own methods when a mutation isn't present

[benbalter]

This is a side effect of monkey patching jekyll/jekyll#6338 into #110.

In jekyll/jekyll#6338 the problem was that Drop#key? needed to call self.class.mutable? not self.class.mutable. Rather than wait on the upstream fix, I monkey patched a modified version of key? with that single character change.

As it turns out, there's more wrong with key? in Jekyll core. If you read through the logic of:

https://github.com/jekyll/jekyll/blob/8b47fb1f7a85d518a21f5fcfd3b20df18c60bf7a/lib/jekyll/drops/drop.rb#L101-L112

You'll see that if a Drop is mutable, and the user hasn't overridden the requested key, the Drop will respond that it doesn't know anything about the key (even if it has a non-mutated native method that's the intended value).

In this case, if a user, for example, calls site.github.url, it'd work fine if they overrode the value, but Liquid, which calls Drop#key? would assume the drop didn't respond to the key since the Drop only looked at mutations.

This PR adds tests for the temporarily monkey-patched methods, and corrects the logic of Drop#key? to look for a corresponding key in the mutable data, in its own methods, and then in the fallback data, responding true if a key exists in any (meaning the Drop could respond to the requested key).

/cc @parkr