Organize global variables by declaring module to accommodate new naming rules

[GuntherRademacher]

Private variables declared in a library module are no longer required to be in the module namespace (see 5.16 Variable Declaration). The corresponding check can be adapted easily, but the management of global variables in the Variables class currently mixes variables from all modules without taking into account where they were declared. As a result, it is not possible to use the same private variable name in multiple modules.

This PR

• groups variables by declaring module to avoid name clashes
• checks the declaring module to prevent main-module variables from becoming visible in imported modules
• allows private variables of a module to be visible in all files comprising that module (as public variables already are)

Tests for this have been added in ModuleTest.visibility.

There is also an unrelated fix for a typo in a built-in record field name in enum Records.

On a side note, the 33 lines of code of Variables.iterator could be reduced to 5 by using streams. I wasn’t sure whether to take advantage of this because of the higher runtime cost. However, as this is surely not a hot spot, we might still go this way:

  @Override
  public Iterator<StaticVar> iterator() {
    return StreamSupport.stream(varsByModule.values().spliterator(), false).flatMap(
        vars -> StreamSupport.stream(vars.values().spliterator(), false)).iterator();
  }

The changed naming rules apply to functions as well, but I’d prefer to address that in a separate task.