Fix existence-element-type confusion

The fix proposed here simply has the GIN code treat both Jsonb keys
(which are always strings), and Jsonb elements that happen to be strings
as keys, while non-string elements are treated as values.  We continue
to treat object values as values within the GIN Jsonb code in all
circumstances.

The definition of key used here is the Jsonb GIN default opclass
definition.  This is a definition distinct from both the generic GIN
definition of a key, and distinct from the generic Jsonb definition of a
key.  Therefore, nothing in the default GIN operator class precludes a
more general notion of containment that allows for consider non-string
JsonbValues (even if that's not terribly compelling).