(PUP-1588) Add msgpack indirector terminii

Adds indirector terminii for catalog, report and node. These are a lot
faster to store than the PSON or YAML equivalents.
(maint) Make msgpack feature do the correct requires
(PUP-1407) Fix specs on 187

In ruby 1.8.7, OpenSSL::X509::Name does not include Comparable, so `==` is
not based on the `<=>` operator. As a result, comparing two Name objects
that have the same string representation will return false. In ruby 1.9,
the class includes the Comparable module. Changed the test to just compare
the String representations.

The other test was failing for me on ruby 187, and it seemed completely
unnecessary to compute 2**158 every time the test runs.
(docs) Update description for Exec type's logoutput parameter

The logoutput parameter can't accept log levels as legal values. This has been
wrong since 2008 (commit bb8051bc406d1da67db8212e852bb36d1368e953) and it sounds
like it was practically wrong long before that.
Merge pull request #2343 from nfagerlund/docs_exec_logoutput

(docs) Update description for Exec type's logoutput parameter
(PUP-1473) Fix issue with UTF-8 in user comments

GH-1943 included a change to munge the comment property on the user
type so that it gets encoded as ASCII-8BIT. This was to allow the comment
property to handle UTF-8 values as existing values are read as ASCII-8BIT.

Originally the change called `force_encoding` to force the encoding to
ASCII-8BIT. This method does not actually attempt to encode the string, it
only changes the string's associated encoding. It was suggested during code
review that a call to `encode` should be used instead. However, calling
`encode` will fail if the string has UTF-8 characters that cannot be
represented in ASCII-8BIT.

As we desire the comment property to be treated as a squence of bytes in
this case, we should be calling `force_encoding` instead of `encode`.
(#3220) crontab: allow purging unmanaged resources

The problem was that unmanaged cronjobs would be parsed, but
not implicitly named.

Workaround: Pick an implicit name. It's derived from the command.
The provider will never put this implicit name into a crontab file
when writing it back to disk.

The names are not unique if several unmanaged jobs execute the same
command. That's a wrinkle and not mission critical, but it can
be surprising for users, because the "duplicates" will not be
purged during the first run.
(#3220) make sure that generated cron resources belong to the correct user

This solves a testing issue that resulted from the #2251 fix. The new
problem is that resources are no longer just looked up by name. Now, the
resource's user property has to match the file being read from disk.
The problem with generated resources is that they use the default user
(i.e., the user running the spec test). Therefor, the resources would now be
considered independent from the crontab records from the testing fixture.

It's fixed by making sure that the respective user property matches the crontab
from which the resources are generated. This is done while the resources are
marked as "being purged" by overriding the Type#purging method.
(#3220) fix a cron testing quirk with potential benefits for normale operation

The integration test for the purging of unmanaged cron resources had
the bizarre side effect of writing vestiges of the fixture to ./$USER
whenever the test was run.

The reason were default should-values for the target property of cron
resources. Per default, the target for any cron resource is the current
user. When generating resources (through the instance method), the
default is erronously used.

When purging, we can fix this by forcing the should-value of each
resource being purged to be the file the resource was generated from.
This is done in the override of the purging method.
(#3220) make the unit test "generating cron resources" match the new behaviour

To allow purging of unmanaged resources, they are now implicitly named.
The unit test must take that into account.
(#3220) save overhead in cron type unit test and add cleanup

As it was, the unit spec for the cron type would register a mock provider
before each example. Add the :all parameter to 'before' to make that happen
only once.

There was a new issue with the integration test for the #3220 fix. The reason
was that the mock provider from the cron unit test would remain in the list of
suitable providers. Purging relies on Type.instances, which in turn tries and
invokes the instances method of all suitable providers. Prevent issues by
removing the mock provider from the list.
(#3220) uniquify implicit record names

Adds an numeric suffix to the artifical name that gets generated for
unnamed records in crontabs. It will suppress naming collisions for cronjobs
that use the exact same command string.
(PUP-1619) Add first impl of working Tuple Type

This adds the Tuple Type which is parameterized with a sequence
of types. The parameters also includes the ability to specify a range
of occurrences of the last type in the sequence (default 1).

This also makes a small refactor of type equality since Tuple and
Array may describe exactly the same type of instance, but it is
neither's responsibility to know this - hence, equality of types
is now performed by the TypeCalculator.

This commit also contains the model part of the PStructType
implementation.
(PUP-1619) Fix problem with parsing Tuple

There was a problem parsing the occurence constraint for the
last type argument (if there was one numeric).

This also adds a test.
(maint) Add Array type size constraint test

A test for Array[T, from, to] was missing.
(PUP-1619) Add more tests of Tuple Type
(PUP-1619) Make Tuple a subtype of Data when its elements are Data
(PUP-1619) Add support for a Struct Type

The Struct Type fully qualifies a hash.
Keys must be non empty Strings. The type of the value is specified
per key.
(PUP-1619) Accept missing struct keys if type for key is optional

A hash with key bound to nil/undef or missing key and the 
struct type accepts nil/undef should be treated as matching.

Without this fix, the hash must has nil/undef bound to keys witout
value.
(maint) Fix issue with type_of not handling Optional type

The Optional Type was treated as a RubyType in the type_of method
because it checked against ObjectType instead of AbstractType.