(PUP-1976) Use metadata.json as canonical metadata source.

Prior to this commit, the Modulefile was used as the primary source of user-facing metadata for modules.  This file was executable Ruby, which was intended to describe a simple data structure.  This causes a few problems for us in the long-term, including making automated module builds a significantly more difficult proposition, and making changes to acceptable metadata a slow process (requiring new releases of Puppet).  In addition, the only piece of Puppet code that interacted directly with the Module file was the `module build` action – anywhere we actually need to know something about the module, we look it up from the metadata.json file.

This commit removes this level of indirection between user input and module data, making the metadata.json file a first-class citizen in Puppet modules.  It similarly deprecates the Modulefile as a supported source of module data.  Checksums have also been moved into their own file (per PE-3124), and `puppet module changes` has been updated to leverage the new file when available (per PE-3120).

For users building a module containing only a Modulefile, this will issue a warning that the Modulefile is deprecated, and output the corresponding metadata.json file.

For users building a module containing both a Modulefile and a metadata.json file, this will issue a warning that the Modulefile is deprecated and is being ignored.
(PUP-1977) Update `puppet module generate` to create `metadata.json`

Prior to this commit, running `puppet module generate` would create a Modulefile with the appropriate metadata, from which a metadata.json file would be generated when you ran `puppet module build`.  Since we're migrating away from the Modulefile as the canonical source of metadata (as per PE-3117), this commit will instead generate an equivalent metadata.json file when the module is created.
Add docs badge to README
(PUP-1892) File resources do not work with fileservers that are not the current puppetmaster.

the source parameter makes the 'uri' method private; assumably for security, the actual result is that
noone can get the full URI from the source param. The end result is that when collecting the source data
the file_content class uses full_path instead, which gets magically completed to use the puppetmaster.

If your fileserver is in fact some other remote host, that data is lost. This change makes 'uri' public
and adjusts the content handler so that it properly delivers either a URI as a string, or a
full path without leading slash (which is what the previous state was.)
(PUP-2093) Integrate a dedicated dependency resolver.

Prior to this commit, we relied on the Forge's /v1 API to handle dependency
resolution for us; as we move away from that (now outdated) API, we will need to
take responsibility for that functionality in our own codebase.

This change vendors our own dependency resolver, as a stopgap measure. This is
not expected to be reused by consumers of Puppet, and will be deprecated and
removed from this codebase when the dependency resolver is properly published.
(PUP-2093) Migrate PMT to /v3 API.

Prior to this commit, the PMT managed all communication with the Forge via the
(now legacy) /v1 API. That API has been deprecated (primarily due to scalability
concerns), which is less of an issue since it was never officially a public API.

This commit migrates all communication to the Forge to the new /v3 API, which is
expected to be launched as our official public API "soon". This commit also
integrates a standalone dependency resolver, as the /v3 API contains no implicit
dependency resolution (as the /v1 API did); consequently, large portions of the
PMT code have been changed, and others have become unreachable.

This commit also changes the default host that the PMT communicates with, from
https://forge.puppetlabs.com to https://forgeapi.puppetlabs.com (the natural
URL for the Forge API service). Since the tool now expects to communicate with
a completely different service, it will be unable to communicate with services
that do not implement the same /v3 API.
Use no-daemonize and not forking service

Making puppet fork and systemd to read PID file seems unnecessary complicated.
Adding dependency on puppetmaster to puppet

Sounds like a good idea to wait with start of puppet agent to finish starting
of puppet mater first.
Make relation between service and sysconfig file obvious

There is puppet service but it's environment file is called puppetagent
(probably due to historical reasons). Making the naming more consistent and
obvious.
(PUP-2093) Restore use of JSON (over PSON).

In master, we've officially introduced a dependency on the JSON library,
but the previous commit in this branch unintentionally reverted a part
of that commit due to merge conflicts.

This commit restores the use of the JSON library where it had been
previously removed.
(PUP-2093) Support hyphenated module names as dependencies.

In master, hyphenated module names are supported (effectively)
everywhere except as the name of a dependency. A previous commit in this
branch attempted to alleviate that situation, but failed to adequately
test the change and its implications, and potential failures existed.

This change introduces a change to existing tests that triggers the
offensive behavior both in master and in this branch, and refactors the
implementation to apply the necessary transliteration in all required
locations.
(PUP-1986) Ignore source_permissions when downloading plugins on POSIX

Module pluginsync is handled by creating a Catalog with a File resource,
and Puppet's File resource defaults to replicating the source file
owner, group and mode. However, owner/group are additionally set to
Process.owner/group for a pluginsync download on POSIX, which will
typically be root during an agent run.

This combination of behavior meant that a root agent run on the puppet
master would cause Puppet's $libdir to be reset to the mode of the first
source module lib, but owned by root.

The puppet master, running as root, chuser's to the service user.  In a
Webrick setup, requests are handled by that service user; in a Rack
setup, it depends on how the Rack service has been setup, but typically
it is the service user again.  So, if the source module had restrictive
permissions, the puppet master, running as the service user, could end
up no longer being able to read $libdir.

On Windows, we were already setting the File type's source_permissions
parameter to :ignore when pluginsyncing.  This commit sets
source_permissions to ignore regardless of the platform, leaving
$libdir's mode unchanged on POSIX as well.

TODO unfortunately this means that owner/group of $libdir are still
being managed on POSIX by pluginsync, which will take precedence over
settings. This seems wrong.
(PUP-2027) Use Callable in Function API

This changes the impl of the Function API to use the Callable type
instead of using a Tuple. This is in preparation for handling
blocks since a Callable type also encodes the functions requirement
regarding a trailing block (no-block, optional, required) and its type
signature.

This also moves the functionality to check argument compatibility to
the TypeCalculator. It now has a callable?(callable, args_type) since
this is different than assignable?
(PUP-2027) Support lambdas in 4x function API

* Adds ability to accept lambdas/blocks in the 4x function API
* Adds ability to define "last arg captures rest"
* Adds CallableSignature as API for information about a callable (was
  different for functions and lambdas earlier)
* Function and Closure now implements CallableSignature
* Refactoring of how evaluator calls functions (no need to assert
function exsistnce separately (just takes time to look up functions
twice).
* TypeCalculator can now infer Callable from Function and Closure
* TypeFactory supports creating Callable with a block type last
* Callable type is given convenience methods to get range of types and
  block (accepted, optional, required).
* Spec tests added for many additional examples (for blocks)
(PUP-2176) Change to correct evaluating parser for puppet function load

The PuppetFunctionInstantiator used the future parser for 3x.
(PUP-2176) Add validation of puppet function name (must be name spaced)

This adds validation in the 4x checker to flag puppet function
names that are not namespaced.
(PUP-2237) Improve puppet-mode indentation, XEmacs compatibility

Handle a closing brace followed by a comma, which is the end of a
selector inside a resource.  Keep indentation at the same level in
that case.

Correctly indent the line following an array ending with :, which
is an array of resource names at the start of a resource definition.

Restore proper indentation following a line with a closing paren
and opening brace.

Properly highlight the resource name when setting defaults for that
resource.

Also clean up some places where \( or \) was used in a string to
represent a literal paren.  The backslash is extraneous here and is
ignored, so omit it.

Fix compatibility with XEmacs.
(PUP-2237) Fix end of string in Emacs autoload for puppet-mode

Autoload file match patterns should end in \\' to match the actual
end of string, not $ to match end of line, just in case file names
contain newlines (not that this is horribly likely, but this is
Emacs best practice).
(PUP-2176) Make loading of puppet functions not nest under modulename

Before this fix, the puppet function loader:
* accepted puppet functions in the global name space
* mapped foo.pp request to <moduleroot>/functions/foo.pp
* mapped mymodule::foo.pp to <moduleroot>/functions/mymodule/foo.pp

Now:
* searches for global names will not find puppet functions.
* mymodule::foo.pp is mapped to <moduleroot>/functions/foo.pp

(requested name vs. actual name was already checked)
(PUP-2101) resource parser: add the resource name on the validation error message when using create_resources