Modules: Testing code likely needs special powers

The in progress Module feature currently has the following section:

> The rules for using types outside of their module are based on the capabilities the type explicitly provides:
>
> * It is a compile-time error to invoke a generative constructor of an abstract class, interface, or mixin outside of the module where the type is defined.
>
> * It is a compile-time error for a type to appear in an extends clause outside of the module where the type is defined unless the type is marked open.
>
> * It is a compile-time error for a type to appear in an implements clause outside of the module where the type is defined unless the type is an interface or is marked interface.
>
> * It is a compile-time error for a type to appear in a with clause outside of the module where the type is defined unless the type is a mixin or is marked mixin.

However, testing code within the same package most likely wants to violate these rules. And possibly even other modules within the same package that aren't just tests.

The most common case for tests would be Mocks or Fakes, which need to be able to `implement` all kinds of classes that exist in the same package, regardless of their stated rules.

## Friend modules?

One way to resolve this would be "friend modules". Friend modules would only be configurable from the originating module, maybe via some "friend ;" directive or other similar mechanism. Any module listed as a friend would have the same capabilities as the current module.

Start with the module access rules quoted in the issue and the concern about mocks and fakes implementing restricted types. Investigate how testing code and other modules in the same package should be handled, then determine whether a friend-module design or another approach is appropriate. Done requires a decided, documented language-design direction.

Written by the indexing model from the issue text.