(#19876) Fix crontab regression in resource matching

The logic for matching new resources with exiting unmanaged cronjobs
has been reworked during the fix for #16809. Somehow, this lead to
a new issue which caused spurious matches, e.g.:

10 * * * * /bin/true

and

cron { "blank": command => "/bin/true", ensure => present }

would now match. At least puppet will not try to change the name of the
record (i.e., the 'Puppet Name:' line). But the new entry will not get
added either. It still works if there is a non-matching time field, e.g.

cron { "blank": command => "/bin/true", hour => 1 }

but without such fields, the behaviour is wrong.

The match method (in the crontab provider) will expressly ignore named
records on disk. This is safe to do; if the resource does have the
same name as the on-disk record, the match method will not even get invoked.

There is no scenario in which we'd want differently named records to be
matched with a resource. If an on-disk record has a name, it either is
managed through another resource, or it used to be managed. Either way,
the resource in question needs adding or matching to a different record.