add debug info
Revisited the transformation.

The byte code for a reference from a subype to a field in a super type is
generated as if the field is available on the subtype. The actual field in
the super-type is discovered at runtime.

Because of this, matching both the owner and the field name doesn't rewrite
all the possible references to a field that might be gone now.

Unless we go build the type hierarchy of entire Java classes in the classloader
(which makes the transformer require context beyond just the current class file image),
this means we can only find out whether the field require rewriting at runtime.

So now if A.i is adaopted to A.i(), anywhere else where a field "i" is referenced
would have to be rewritten for a precaution:

For example, given

  B b = ...;
  b.i = 4;

It'd have to be transformed as follows:

  B b = ...;
  if (A.class.isAssignableFrom(B.class)) {
    b.i(4);
  } else {
    b.i = 4;
  }

Fortunately, Class.isAssignableFrom is one of the HotSpot intrinsic function,
meaning when both sides are constants like above, it gets inlined, and turns into:

  B b = ...;
  b.i = 4;

or

  B b = ...;
  b.i(4);

depending on whether B is actually a subtype of A.

The other issue is that the target of rewrite is quite extensive, given that it just
relies on name. In the next commit, I'll improve AdaptField to specify the former types
of the field.