Role file could no longer find its enclosing team

Documenting an issue hotfixed via commit a423edb9:

For unclear reasons, a role file could no longer locate its enclosing team.

• The toplevel package was a split package ("org", with several incarnations from JDK modules)
• In one incarnation ("unnamed") the full package & type was known, but SPB.getPackage0() refuses to answer the binding if some incarnations haven't yet cached existence/non-existence of that package.
• Falling back to LE.askForType(), however, let the NameEnvironment answer null, because it found the full type name in the list of initial compilation units and so assumed that the type must already be known to the compiler.

Solution:

• LE.getTeamForRoFi() now has an option to ask the enclosing module for a declared package (thus bypassing unrelated modules).
• For that purpose RoleFileHelper.getTeamOfRoleFile() needs to select the environment of the enclosing module
• We assume the qualified team name to refer to a toplevel type, which I believe is given for containers of a role file (hence splitting the FQN at the last segment should be kosher).