Increase minimum required Remoting version from 4.13 to 3107.v665000b_51092

[basil]

The current minimum Remoting version (4.13) is now 2 years and 4 months old. This PR bumps the minimum Remoting version to 3107.v665000b_51092, which is 1 year and 5 months old, effectively raising the minimum Remoting version by 1 year. I still think that ~1.5 years is a generous amount of time for people to upgrade agents, and it benefits the ecosystem to have agents running on a recent version of Remoting with bug fixes and dependency updates. We have had no issues previously raising the minimum Remoting version in #7340, #6671, and #8484.

Testing done

This use case is covered by test automation; specifically, jenkins.slaves.OldRemotingAgentTest, jenkins.slaves.UnsupportedRemotingAgentEscapeHatchTest and jenkins.slaves.UnsupportedRemotingAgentTest. I ran all of these tests (and more) locally with:

mvn clean verify -Dtest=hudson.slaves.ChannelPingerTest,hudson.slaves.JNLPLauncherTest,hudson.slaves.PingThreadTest,hudson.slaves.SlaveComputerTest,jenkins.agents.WebSocketAgentsTest,jenkins.security.AgentToControllerSecurityTest,jenkins.security.CustomClassFilterTest,jenkins.slaves.OldRemotingAgentTest,jenkins.slaves.RemotingVersionInfoTest,jenkins.slaves.UnsupportedRemotingAgentEscapeHatchTest,jenkins.slaves.UnsupportedRemotingAgentTest

Proposed changelog entries

Increase the minimum required Remoting version to 3107.v665000b_51092 (released on February 2, 2023).

Proposed upgrade guidelines

Increase the minimum required Remoting version to 3107.v665000b_51092 (released on February 2, 2023). When an agent with a Remoting version older than 3107.v665000b_51092 connects to the Jenkins controller, the agent connection is rejected. Ensure that all agents are running a recent version of Remoting prior to upgrading. Agents with unsupported Remoting versions can be allowed to connect to the controller by setting the hudson.slaves.SlaveComputer.allowUnsupportedRemotingVersions system property to true.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

### Maintainer checklist
- [ ] There are at least two (2) approvals for the pull request and no outstanding requests for change.
- [ ] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
- [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood.
- [ ] Proper changelog labels are set so that the changelog can be generated automatically.
- [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](https://github.com/jenkinsci/jenkins/pull/4387)).
- [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)).

[MarkEWaite]

Thanks!

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge