feat(api): Centralize the logic to read feature flag values (#29900)

[spbolton]

Proposed Changes

• Add alternative filtering and selection to /v1/configuration/config endpoint
• either original "keys" html parameter can be used or the following new optional parameters contains, startsWith, endsWith and caseSensitive (default false)
• When case insensitive matching is enabled which is the default underscores are replaced with "." for matching the original key is returned

Things to think about

• Not all properties keys in use in the system may not be loaded from the environment or config files and will only be returned if they have been queried.
• This exposes inconsistencies in the config property nameing that we should separately address but is still useful now.
• We need to be aware of whether this introduces any security risks we need to tie down.
• For a base system we are probably ok without paging or restricting the results returned, but we may need to think about this.
• The results are all returned as string values, this should be ok leaving any convesion to the client but we need to be aware of this and confirm all types are being returned in a way that can be processed
• We will need to confirm the performance and how many keys we may be dealing with
• If there are no security limitations of this endpoint and the original "keys" property works as before we would be safe to merge this and then follow up with any UI changes to make use of this

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

This PR resolves #29900 (Centralize the logic to read feature flag values).

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

[dotcms-sonarqube]

Quality Gate passed

Issues
1 New issue
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[nollymar]

Before merging this PR, I want to make sure that we have a real need to implement the filtering. Have we identified a real need from FE, support, etc?
If so, my only suggestion would to be to include a postman test.

[jdotcms]

I think StringUtils.isSet does this

[jdotcms]

I think this can be perform with a Stream such as

Stream.of(key).map(this::removePrefix).filter....

[jdotcms]

I feel this should be in another place

[jdotcms]

I have left some comments but in general is a good improve for the configs