IdStore.getId() and make() methods support the non-migrated data as a fallback

[oleg-nenashev]

This change allows to operate properly if the data has not been migrated correctly or has been loaded after the start (Job Config History, Manual copy, etc.). Also extends and fixes unit tests.

@reviewbybees

[oleg-nenashev]

FAQ: Yes, I want to merge it to @jtnord 's branch

[jtnord]

@oleg-nenashev There should not be a need for the legacy lookup.
If the legacy migration fails then this will bomb out and it should be re-attempted at next startup.

The legacy actions must be removed - otherwise the root issue still exists (an item when copied may return duplicate information).

[oleg-nenashev]

@jtnord
We cannot guarantee that the user does not load the config after the restart somehow.
What about also patching JobIdProperty.onLoad()?

[jtnord]

@oleg-nenashev if they load the config after restart - then it is likely that the user has copied the job - in which case we will be migrating bad data.
We will already have to document that if the user has copied jobs they will need to do something to fix things (as we can't just arbitrarily create a new unique string as that will break everything that used the old unique string if there are no conflicts.) Conflicts can exist on different masters so we can not even hope to keep track of these (allthough we could make a best effort to do so and spit out a warning...)

[oleg-nenashev]

I don't completely agree with such approach if we use a multi-instance Jenkins installation, which transfer jobs between each other somehow. Without this patch there won't be an opportunity of one-by-one upgrade.