DEBUGGING: regression with unnamed cron entries
(#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 an edge case wrt. the generating of additional graph edges

The fix for #22229 saw fit to add a graph edge for each generated resource,
originating from the container of whichever resource was responsible for
the generating in the first place.

In any regular catalog, this will work without issue. During integration
testing of the cron provider, however, artificial catalogs are used in which
there is not even a Main class to contain all globally scoped resources.
As a result, the test would not run because of the dangling edge.

To keep this from happening, add a sanity check to the code that is
responsible for creating the additional edges.
(#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.