[lworld] Provide experimental support for generating a single class file per primitive class

Requirements:

    - Provide an experimental mode controlled by a javac command line option (off by default), under which javac will translate a primitive class (say class Point) into a single class file (Point.class) artifact instead of the present two class file scheme (Point$ref.class and Point$val.class/Point.class)

    - On the language side, Point.val and Point.ref will continue to be two distinct types standing for the value projection and reference projection. But javac backend would generate a single class file Point.class as output

   - The class file will use L/Q forms to denote the two variants in descriptors. That is, in field and method signatures, today’s "LPoint$ref;" and "QPoint$val;"/"QPoint;" will become respectively "LPoint;" and "QPoint;”.

    - For places where we need conversion between the two types (QFoo and LFoo) we will issue casts.

    - ATM, a cast takes a class info, not a descriptor. There's a proposal on the table to emit a special class info that uses a
descriptor in the Utf8 of a class

    - The CONSTANT_Class_info syntax would be the following: To express the L-type (Point.ref) the CONSTANT_Class_info contains an index to an Utf-8 with the name of the class “Point”. And to express the Q-type (Point) the CONSTANT_Class_info contains an index to an Utf-8 with a full descriptor “QPoint;”

    - A CONSTANT_Class_info with the descriptor can be used by any bytecode that needs to make the distinction between the L-type and the Q-type: checkcast, instanceof, anewarray, ldc.

    - Should defaultvalue use a class name or a descriptor is TBD, but this is not a big deal, because there’s no ambiguity in the semantic.

    - At this point, the model is not using type restrictions, the Q marker in descriptor continues to mean the same thing: non-nullable reference to a primitive object. This means, the produced bytecodes will continue to be verified by the JVM with the same rules as today.

    - There are no additional attributes to be generated.

    - One constraint from the VM side is that we cannot simply switch to the current model to the L/Q model in a single step, there’re too many components to be updated. So, instead of breaking the repo for weeks, we’d like to have flag in javac to generate class files with the L/Q model, so we can start working on the transition, without breaking the main branch and impacting the works in progress (especially from the community).