Support multiple redirect_uris when creating OAuth 2.0 Applications

[ThisIsMissEm]

This brings us more inline with the dynamic client registration specification, where you can create a single application with multiple redirect URIs, see the example request at: https://datatracker.ietf.org/doc/html/rfc7591#section-3.1

This works around some weirdness in doorkeeper, where it only has a redirect_uri field on an Application, but it does some weird "join multiple values with a \n for the database" thing.

Arguably, this could be considered a breaking change because it introduces some kinda weird behavior, but it is technically the "correct" behavior with regards to OAuth 2.0...

This is currently a draft as it requires test coverage to be written, and I have had the time to write said tests yet.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.01%. Comparing base (86500e3) to head (c43497a).
Report is 665 commits behind head on main.

❗ Current head c43497a differs from pull request most recent head d8cc3f3. Consider uploading reports for the commit d8cc3f3 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #29192      +/-   ##
==========================================
- Coverage   85.01%   85.01%   -0.01%     
==========================================
  Files        1059     1060       +1     
  Lines       28277    28288      +11     
  Branches     4538     4537       -1     
==========================================
+ Hits        24040    24049       +9     
- Misses       3074     3075       +1     
- Partials     1163     1164       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ThisIsMissEm]

The following issue was discovered whilst working on the tests: #30152

[ThisIsMissEm]

Working on a few additional changes after noticing some gaps when authoring the documentation for this PR.

[ThisIsMissEm]

@ClearlyClaire okay, we're good — I've added:

• exposing the redirect_uris property from /api/v1/apps/verify_credentials (we had started to expose client_id and scopes in Feature: Allow oauth application introspection without read scope #27142 )
• added test case to ensure /api/v1/apps/verify_credentials never exposes client_secret (just in case the controller is changed in the future)
• Moved the redirect_uris method from the serializer to the Doorkeeper::Application extension (I feel like this is cleaner)

[ClearlyClaire]

Looks good to me although I'm confused why this is going back on client_id being introspectable.