Accept maintainer_note parameter in REST runner registration

What does this MR do and why?

Describe in detail what your merge request does and why.

This MR adds support for taking in a maintainer_note field in the runner registration endpoint. A gitlab/gitlab-runner MR will soon take advantage from this addition so as to allow an admin to specify notes to be associated with the new runner.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Part of #348299 (closed)

doc/architecture/blueprints/ci_data_decay/index.md

@@ -16,7 +16,7 @@ and has become [one of the most beloved CI/CD solutions](https://about.gitlab.co
 
 On February 1st, 2021, a billionth CI/CD build was created and the number of
 builds is growing exponentially. We expect to see 20M builds created daily on
-GitLab.com in the late of 2024.
+GitLab.com in late 2024.
 
 GitLab CI/CD has come a long way since the initial release, but the design of
 the data storage for pipeline builds remains almost the same since 2012. In
@@ -71,7 +71,7 @@ Currently, storing pipeline processing data is expensive as this kind of CI/CD
 data represents a significant portion of data stored in CI/CD tables. Once we
 restrict access to processing archived pipelines, we can move this metadata to
 a different place - preferably object storage - and make it accessible on
-demand, when it is really needed again (for example for compliance purposes).
+demand, when it is really needed again (for example for compliance or auditing purposes).
 
 Epic: [Link]