[JENKINS-75902] Always save a timestamp of the latest GitLab project configurations into the config, signalling this plugin has done some work

[Pitxyoki]

This change continues the work done in jenkinsci#495.

We found that this plugins' GitLabSCMSource#retrieve() methods are called when the job-dsl-plugin's jobDsl() method is called.
If at those points the code in this plugin fails to communicate with GitLab, the config.xml file corresponding to the pipeline being parsed is saved without any information that would come from this project's GitLab project (i.e.: sshRemote, httpRemote,
projectId will not exist). The contents of that file will be the same as if this plugin hadn't executed.

When the jobDsl() method is called again at a later time, it compares the saved config.xml to the config.xml it expects to save at that point. See https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-plugin/src/main/java/javaposse/jobdsl/plugin/JenkinsJobManagement.java#L453.
Note that at that point, the new expected config.xml that the job-dsl-plugin uses for that diff does not have any information that should come from the gitlab-branch-source-plugin.
As such, at that point both the base config.xml as well as the expected-to-save config.xml are equal.

This change adds a new field to the pipeline's configuration, lastRetrieveTimestamp, that is updated at every attempt to update it, regardless of the GitLab communication having succeeded or not. In this way, the attempted diff by the job-dsl-plugin will always trigger an update and corresponding reattempt at communicating with GitLab, preventing previous failures from avoiding that.

Testing done

Similarly to jenkinsci#495, we deployed a patched gitlab-branch-source-plugin with both that and this change into our running Jenkins. We have not seen the issue reoccurring and will keep on observing it in the next weeks. We will notify if we see this wasn't effective.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed