Fix length limitation of secrets and passwords

Articel describes the limitation of bcrypt. If a secret (or password) in UAA has more than 72 characters, then these
characters are not used, e.g.
https://sendoh-daten.medium.com/using-bcrypt-as-password-encoder-can-be-problematic-when-passwords-are-non-ascii-characters-a5ac0478aeed

Example with dev. UAA:
uaac client add test --name test --authorized_grant_types client_credentials -s 'this-is-a-secret-which-is-not-longer-then-what-bcrypt-can-handle-matches'

uaac client client get test -s 'this-is-a-secret-which-is-not-longer-then-what-bcrypt-can-handle-matches'
works but also
uaac client client get test -s 'this-is-a-secret-which-is-not-longer-then-what-bcrypt-can-handle-matchesXXXXXXXXXX'
uaac client client get test -s 'this-is-a-secret-which-is-not-longer-then-what-bcrypt-can-handle-matches-more-than-wanted'

In this generator another weakness gets visible. UAA uses by default factor 10, but 12 is now the recommended one
https://bcrypt-generator.com/

Start by reproducing the client-secret examples against a development UAA and trace the password and secret encoding configuration that uses bcrypt. Determine how longer secrets should be handled and whether the cost factor should change; done means added coverage demonstrates that extra characters affect authentication and the agreed bcrypt strength is applied.