Proposal: #ClassFileAccModule

[mark.reinhold at oracle.com]

Issue summary
-------------

  #ClassFileAccModule --- The `ACC_MODULE` constant is currently
  specified to have the value 0x8000.  This is the last available bit
  remaining across all of the various `access_flags` fields of a class
  file, and thus should be reserved for some unspecified future purpose
  where it may be useful to use the same value in all such fields.
  Alternative candidates for `ACC_MODULE` include 0x0040 (overlaps with
  `ACC_VOLATILE` and `ACC_BRIDGE`) and 0x0080 (`ACC_TRANSIENT` and
  `ACC_VARARGS`). [1]

Proposal
--------

Do not change the value of this constant.

The high-order bits of the `access_flags` field have long been used to
characterize the unusual, non-class nature of some class files:

  - `ACC_ANNOTATION` (0x2000) indicates an annotation type, even though
    `ACC_ANNOTATION` does not apply to fields or methods, and

  - `ACC_ENUM` (0x4000) indicates an `enum` type, even though `ACC_ENUM`
    does not apply to methods.

A binary module descriptor is a new kind of unusual class file, hence we
have done the obvious thing and allocated the high-order bit 0x8000 for
`ACC_MODULE`.

We could try to be more clever here, but that would require attempting
to predict the future.  There are still plenty of other ways to encode
potential future features; a value class could, e.g., be indicated by
0x0100.  In the worst case the `access_flags` field could simply be made
wider in some future version of the class-file specification.


[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFileAccModule