(PUP-1585) cron: fix resource duplication in crontab provider

The regression fix for #19876 caused yet another regression in cron
resources that manage the target property, but not the user property.
The earlier fix made sure that a cron resource would not try and manage
a matching record from another user's crontab. It did so by comparing
the record's target to the resource's user property.

When the user is unmanaged, but the target is specified instead, this
would cause puppet to ignore the record on disk and add it once more.

This is fixed by comparing the record's target to either the user
property or the target property. If there is a should-value for the
user, it is used, otherwise the provider falls back to the target
should-value.
(PUP-1585) amend unit test to match corrected behavior

Just a simple addition to the mock object used for some tests, because
the crontab provider will now perform an additional property value lookup
to find an on-disk resource.
(PUP-1624) cron: move the default value logic from user to target

Crontab is an oddball example for parsedfile resources, because resources don't
end up in actual files, but I/O is indirected through crontab(1) instead.
Therefor, the target property doesn't really apply and maps to the user
property instead, after a fashion - the user that runs the cron task is
determined by which crontab the entry is stored in.

For default values, it was determined that the user property should be
processed before the target property (on type level) and choose the default
(i.e. the user running puppet). The target property would use the value
of user as its default.

This leads to a peculiar situation when target is managed but user is not.
User *will* use its default value then, which will often differ from the
choice made for target. Puppet will then try and bring the user property
in sync with the default value.

To evade this, a default value for the user property should be avoided,
at least for resources that use the crontab provider. The current rules:

1. The 'user' property uses the user running puppet as default.
2. When crontab is in use, 'target' uses the 'user' value as default.
3. For other parsedfile providers, 'target' uses the provider's default.

Instead, apply the following rules:

1. When crontab is in use, 'user' has no default value.
2. Otherwise, the default is the user running puppet.
3. If crontab is in use and there is a 'user' value, 'target' defaults to that.
4. If crontab is in use and there is no 'user' value, 'target' defaults to the
user running puppet.
5. For other parsedfile providers, 'target' uses the provider's default.
(PUP-1624) cron: fix a unit test regression

The cron unit tests make use of an artificial trivial provider.
Therefor the type code should not traverse code paths that apply only
when the crontab provider is used. For some reason, this didn't work
correctly when the provider was stubbed in place 'before :all' instead of
'before :each'.

As a result, this following test failed because of the change to the
behavior of the user property when using crontab:

Puppet::Type::Cron should default to user => root
  if Etc.getpwuid(Process.uid) returns nil (#12357)

Restructure the hooks to make the behavioral check pass again.
Merge pull request #2342 from ffrank/ticket/master/PUP-1585-cron-duplication-with-target

(PUP-1585) and (PUP-1624) cron: handle the user and target properties better