Review Request JDK-8244090: public lookup should find public members of public exported types

[Mandy Chung]

Prior to JDK-8173978, publicLookup().in(C.class) produces a Lookup 
object on C with PUBLIC access which can be used to look up 
unconditionally exported public types from the module of C. Such lookup 
can only look up this C class defined by loader 1 but not another class 
named "C" defined by loader 2.

JDK-8173978 adds the support for cross-module teleporting. 
publicLookup().in(C.class) was changed to produce a public Lookup i.e. 
with UNCONDITIONAL access.  A public lookup should be able to look up 
public members of any unconditionally exported public types including a 
class named "C" loaded by different loaders.  It reveals a bug in VM 
resolution for Lookup API that adds the loader constraints with 
java.lang.Object as the accessor that constraints a public lookup to 
load one type named C but any more.

The lookup class of a public lookup is irrelevant to the lookup 
context.  Type consistency on P/Q/R live Class objects from the given 
MethodType (MT)is ensured at the following:
1. P/Q/R are consistent from the loader of the declaring class of the 
resolved member (D's loader)
2. P/Q/R are consistent w.r.t. the invoking class and the caller's MT at 
invocation time (the method handle carries the caller's MT that will be 
verified).

The loader constraints added for public lookup is not necessary and adds 
undesirable constraints.  The proposed fixis to skip adding loader 
constraints if the lookup mode is either TRUSTED or UNCONDITIONAL.

Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8244090/webrev.00/index.html

Thanks
Mandy