Container org.eclipse.jdt.MODULE_PATH hides problems in CompletionTests9

Work on #2169 / #2358 raised some suspicion regarding:

1. class path container "org.eclipse.jdt.MODULE_PATH"
2. the interplay of different strategies within SearchableEnvironment.findPackages(char[], ISearchRequestor, IPackageFragmentRoot[], boolean)

(1) is a strawman from the early module days. Its contents is backed by `ModuleSourcePathManager` which simply enumerates all modular projects in the workspace. There is *no* support for binary modules. This was to be an equivalent of PDE's container "org.eclipse.pde.core.requiredPlugins", but the module path container never really took off. I don't recall that it was ever publicly documented.

(2) combines two searches:
* the first is driven just by what the current `JavaProject` can see, i.e., all `IPackageFragmentRoots` etc.
* second a "semantic" traversal of module descriptions to find all exported packages of directly or transitively required modules

Tests in CompletionTests9, in particular those from [bug 519417](https://bugs.eclipse.org/bugs/show_bug.cgi?id=519417), use the module path container. If I change the project structure from module path container to regular project dependencies, then already `nameLookup.seekPackageFragments(..)` finds more packages including some that should not be seen.

It's the addition from bug 519417 which caused grief in #2169

I think it's time to retire the container "org.eclipse.jdt.MODULE_PATH". When comparing to the PDE container, we never came up with an equivalent of a target platform. Just searching workspace projects doesn't suffice.

But when we require "regular" project dependencies between modular projects, then CompletionTests9 reveals more problems.