Fix #2529: explicit protection package #3651

[Chris Nicholson-Sauls via Digitalmars-d-announce]

module foo.bar.one;
module foo.bar.internals; // package-protected utilities
module foo.bar.subpkg.two;
module foo.bar.subpkg.internals; // package-protected utilities


Current situation: module 'one' cannot access the 'bar.subpkg' 
utilities, and module 'two' cannot access the 'bar' utilities.  
This is needlessly limiting, forcing design choices that should 
not be dictated by the ability/inability to separate public and 
private API.  It also precludes many valid and good uses of 
nested package.d modules.

I really don't see any equally strong counter-argument.  But 
then, I've wanted this exact fix for literally years now.

It also is not limited to internal utility modules.  It can be 
useful for systems that select at compile time from one of a 
number of system-specific implementations of a given 
interface/api.  It can be useful for granting privileged access 
to certain api's and/or resources to specific module(s).  An 
example being: grant access to unsafe but versitile data 
manipulators solely to the subpackage containing the loaders.

Currently, there is no absolutely enforceable way of doing such 
things; so one ends up falling back on convention... and 
conventions, sadly, never hold in the real world for long.