Add possibility to schedule builds via a timer

[mawinter69]

The approach to scheduler the build by adding it to the queue with a delay has some disadvantages. When someone triggers a build the regular way that can lead to the scheduled execution to be lost.
This change adds another way of scheduling that will add the execution internally to an internal list. A periodic background work will run every minute and start the build accordingly.
This approach also allows the define a dedicated cause and to decide whether to skip execution when the schedule is missed (e.g. because Jenkins was down).
Parameters are now entered on the same page where the schedule is entered, avoiding the problem that the schedule time was not exact for parameterized jobs.
As the new mode is not adding things to the queue immediately, an additional page is added where the planned builds are listed with time and parameters and given proper permissions to cancel them.

this fixes the following tickets:

• JENKINS-72089
• JENKINS-71103
• JENKINS-59612

Open points:

• react on rename/move of jobs
• configurable grace period for missed builds
• update documentation
• Add tests

Screenshots:

Testing done

• Interactive testing with jobs with and without parameters, starting with old mode and new mode
• Verified that entries survive a Jenkins restart
• A scheduled build without trigger on missed is not started when missed
• Verified that configuring with CasC doesn't lead to loss of schedules on restart
• Cancelling a scheduled build works
• renaming and moving jobs that have a scheduled build
• Permission checks work as expected
  • User with Cancel permission but not build permission can cancel scheduled builds but not schedule new builds
  • User with build permission but not cancel permission can start new scheduled builds but not cancel scheduled builds
  • User with read only can see scheduled builds but not start or cancel

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

[MarkEWaite]

@mawinter69 I think this is a great approach but I don't use the schedule build plugin enough to justify the testing to merge it. I think it would be best if I removed myself as a maintainer and let you be the sole maintainer of the plugin. You are welcome to merge and release this pull request at any time.

Would you be OK if I remove myself as a maintainer of the plugin and left you as the sole maintainer?

[mawinter69]

Actually as of now I'm not a maintainer at all. I don't have any permissions.

[MarkEWaite]

Actually as of now I'm not a maintainer at all. I don't have any permissions.

My mistake. Are you interested in being the maintainer?