Draft: Add spam/CAPTCHA protection for issue notes creation

What does this MR do?

Adds spam/CAPTCHA protection to creation of notes on issues. See https://gitlab.com/gitlab-org/gitlab/-/issues/320799 for details.

Tasks

• Convert to "new" frontend modal approach - see details in the various refactoring MRs in the "Convert CAPTCHA client-server communication to use headers and GraphQL top-level-error instead of fields on the resource" section of the CAPTCHA epic
• Convert to "new" backend controller/service approach - see details in the various refactoring MRs in the "Convert existing issue title/description CAPTCHA to use new modal" section of the CAPTCHA epic
• Ensure everything works everywhere a note can be created or updated 😉

CURRENT STATUS AND REMAINING WORK AS OF 2021-08-16:

1. This MR currently only has a minimal semi-functional implementation which handles happy-path CAPTCHA modal for note creation and update on the issue form.
2. There is a lot left to do, including (this is far from a complete list)
   1. Adding backend support to everywhere a note can be created or updated
   2. Handling any problems on the frontend due to the modal handling being injected into the request flow
3. Special attention is needed to refactoring the relevant Note-related services to the new style of named-argument constructor which takes spam_params as an argument. See !59182 (merged) and !62532 (merged) for previous examples and detailed explanation of this type of refactoring

UPDATE 2022-05-05: See latest status in "Support spam check during notes (comments) creation" section of CAPTCHA epic description

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team