Disallow manifests from declaring things outside the namespace implied by their filenames

This ticket captures and elaborates on a decision made on the developer mailing list in late September 2014 (see email thread "PL RFC-1: Semantics of autoloaded classes").

The contents of autoloaded .pp files should be restricted as follows:

1. All classes defined in the file must have a name that matches the filename, or is nested within the namespace implied by the filename. So, for example, a file foo.pp can contain classes called "foo", "foo::bar", "foo::bar::baz", or "foo::baz", but not "bar".

2. In files that are in subfolders, the portions of the path are joined by "::" to determine what classes are allowed. So, for example, a file foo/bar.pp can contain classes called "foo::bar" or "foo::bar::baz", but not "foo" or "foo::baz". NOTE: class foo is NOT allowed if that is in foo/bar.pp:

class foo { class bar { ... } }").

But this is ok in foo.pp:

class foo { ... }

3. Defines follow similar rules

4. No toplevel constructs (resources, variable assignments, include statements, import statements, etc) are allowed in autoloaded modules.

5. In files that are autoloaded from modules, the module name is included in the path, but the subdirectory "manifests" is not. So for example, the file $module_path/foo/manifests/bar.pp follows the same rules as {{ foo/bar.pp}}.

6. In a module's init.pp file, "init" is not included in the path. So for example, the file $module_path/foo/manifests/init.pp follows the same rules as foo.pp.

7. Everything that is loaded from the enviroment is allowed to use any namespace. (This is also the exploratory mode when writing example snippets).

Because of the pervasive nature of this change, we plan to implement a deprecation warning in one release, to warn users of the impending change, and defer the actual change to a later release. This ticket is for the actual change. PUP-4242 is the deprecation warning ticket.