Correctly handle caller-sensitive methods.

Starting from JDK7u40, it is possible to identify caller-sensitive
methods and constructors (collectively referred henceforth as "methods")
in the Oracle JDK as ones having the sun.reflect.CallerSensitive
annotation. Such methods have some special properties when being used
with MethodHandles.Lookup.unreflect() and unreflectConstructor():
a) They can't be unreflected with a publicLookup() instance.
b) Their unreflected MethodHandles are bound to the lookupClass of the
   Lookup object that unreflected them as their caller.

For these reasons, Dynalink now handles such members separately.
Notably, method handles for such members are never cached, but whenever
linkage is requested, a new method handle will be unreflected using the
Lookup object associated with that single linking request.

Note that Dynalink makes no attempt to correct usage of public lookup
when linking caller-sensitive methods; if a caller tries to link to a
caller-sensitive method by passing publicLookup() instance to Dynalink,
such requests will fail with an exception originating in the
java.lang.invoke.* code.

Caller-sensitive methods were linked by Dynalink even before this change
was made, using a Lookup object with a zero-privilege proxy class as its
lookup class. (This is still the way non-caller-sensitive methods are
linked.) Therefore, these methods were always bound to a zero-privilege
proxy as their caller class, effectively making them unusable for any
practical purpose. With this change, caller-sensitive methods are
usable. For example, you can do INVOKEDYNAMIC of
AccessController.doPrivileged() from your scripts and it'll work as
expected as long as you pass your script's class Lookup.