(#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.
(maint) cron: change the integration tests to rely on the compiler

The artificial catalogs that had previously been used for integration
testing are prone to issues, e.g. the containment of generated resources
would not work and lead to invalid catalogs and failing tests.

Instead of mock resources in patchwork catalogs, use actual manifests
and the compiler to end up with more realistic test cases.

WIP: Sadly, the catalogs don't lead to the expected results when applied.