Data types are initialized with a set of accessors for the
requested fields, which allows caching those accessors and
avoiding costly hash lookups for future accesses. Due to a bug in
how these accessors are initialized, parent and subclasses may
have a different view of how those fields are stored in the object.

Here, the cached accessors are iterated, but then not used to read
the field. This results in a second field being created for the
subclass, in a different order from definition time. Using the
original accessor here accesses the correct field.

Fixes jruby#9241.

Note that there's other problems with the data layout inside a Data
type and other fixes will be needed to clean up how these accessors
are allocated and shared with subclasses.

There's a few changes here to support Data types and their
subclasses:

* Always copy the variable table manager from parent to child,
  unless the parent is Object. This ensures that Data type
  subclasses still see the same accessors and likely makes sense
  for most other classes that inherit instance variables.
* Fix the definition sequence for Data fields to specialize and
  properly use the field-based accessors rather than the growable
  varTable accessors. This maintains a compact store for Data
  fields where previously the object was specialized but variables
  still were stored in varTable.

This relates to and partially fixes some root causes of the Data
type subclass issues reported in jruby#9241.

There are other concerns with this structure of Data, however,
since it may use accessors from the parent in the child (rather
than the cloned versions for the child). We need a larger overhaul
of both Data and how the variable table manager is propagated from
parents to children (previously no propagation happened and all
child classes re-discovered their own instance variables).