(PUP-3268) Issue/master/pup 3268 remove legacy environments

These commits remove support for legacy environments in Puppet 4. It also removes all the watch file code in Puppet::Node::Environment as this was only being used for legacy environments.

Sections other than [main], [master], [agent], [user] in puppet.conf now raise an error when Puppet initializes.

Setting manifest, modulepath or config_version in puppet.conf raises an error when Puppet initializes.

The environmentpath setting is no longer a feature flag, and has a default of $confdir/environments. Puppet will load environments from this path.

The templatedir and manifestdir settings have been removed.

The deprecated Puppet::Node::Environment.current method is removed.

There are additional refactorings of environment, settings and module code, and of some specs.

It needs overall review, and in particular I'm wondering about these areas:

* In commit f0d1c98 ('Do not lookup [legacy] puppet.conf section'): here I added a Struct for elements of the Setting searchpath that represent different settings layers so that we can distinguish the difference between arbitrarily named environment setting layers and other layers which might collide with that namespace (env:main and puppet.conf [main] for instance...)
* @hlindberg,  Puppet::Node::Environment#check_for_reparse has changed.  I believe it is currently testing if the Puppet[:code] has changed or last parse of the environment failed.  Do its cases still look sane, or is it not needed?
* Does anyone have an opinion about whether we can get rid of the cached_attr(:modules) in Puppet::Node::Environment, and replace it with a regular accessor around an instance variable.  I believe the modules attr should just be cached with the environment now and not need a filetimeout?
is this still relevant to test? Earlier the known_resource_type was one of the things that floated around as a separate entity and there was management of it as a global thing that environments switched between in complex twists and turns. Now (IIRC) it is just an attribute of the environment, and should really be of concern outside of the environment... (but maybe additional cleanup and refactoring is required... that we can do later)