Add template support for Imports

When importing with Civi-Import it should be possible to use an existing job as a Template - the UserJob table has a is_template field for this purpose. Without this using SavedMappings is painful as some fields may not load and map. For example the contact field 'Gender' is only available if the contact option is update or create (not the default 'match') so this won't load when the screen is loaded if we are not also loading the relevant options that go with it. Template UserJobs would also be useful outside of Civi-Import for the purposes of loading basic repetitive configuration such as Contact Type, dedupe rule & date format

I do see template UserJobs as eventually replacing saved mappings for imports entirely. There is a 'clone action' aspect to this but I no longer see it being important to resolve that right now.

The way I imagine it working is that

1. if template_id is in the url then the code loads the values for that UserJob assuming is_template is TRUE on the DataSource form. This would use checkPermissions = FALSE because otherwise only the creator can access a UserJob. (if the template_id is passed in the field to select a mapping would be frozen on the DataSource form)

2. a user job template would be updated in sync with the civicrm_mapping record. There is already code for Update & save in a fairly tricksie way on the MapField screen and I propose to soft-link them by virtue of them having the same name - so if a Mapping is created or updated a template UserJob with the same name would be too. This makes for a fairly low level of intervention and works with the existing UI, happening when the MapField is submitted without any change of fields.

The above is moderately simple the question is how to keep the 2 in sync. On one level it is easy as there are NO template UserJobs in use as yet and existing records have empty name fields - so we have Mapping records without UserJobs but not the reverse. As long as we ensure a UserJob of the same name (perhaps with a prefix) is created at the right point of time & deleting it if the Mapping gets created we can reasonably keep them in sync. The job would be updated from the form when the mapping is (I think we can ignore the possibility people would update the mapping in any other way)

A question remains as to how we would originally create the UserJobs. There are 3 options as I see them

1. on upgrade create a UserJob for all existing civicrm_mapping records that relate to registered import types. This is probably the cleanest from a code point of view. The metadata would basically be an empty array

2. when a mapping is selected on the DataSource form then in postProcess ensure the Template UserJob exists

3. when a mapping is selected on the DataSource form then if postProcess ensure the Template UserJob exists IF Civi-Import is enabled and / or IF the import in use is the Contribution Import.

A couple of notes

1. Template UserJobs are more flexible that civicrm_mapping and I expect they will become the way to go
2. While I see the addition of template_id in the url as being sufficient to load a template I expect the path to do that will be a SearchDisplay in Civi-Import - so it would be a hidden feature with that disabled
3. The Template is still useful (if added manually to the url) even without CiviImport for loading details on DataSource
4. I suspect a one-off create of the templates on upgrade is likely most maintainable but
5. Option 3 does lower our surface area if there are are any problems