[fix](be) Mask private key password in backend configuration

[dzr171712]

What problem does this PR solve?

Issue Number: close #CIR-27839

Related PR: #xxx

Problem Summary:

The tls_private_key_password configuration value is exposed in plaintext through information_schema.backend_configuration.

The value is collected by config::get_config_info() from the BE configuration map and returned without masking. Since the default role has read access to information_schema.*, an authenticated user can query the table and obtain the TLS private key password.

This change masks tls_private_key_password as ****** at the shared configuration export layer. The masking applies to information_schema.backend_configuration and other output paths that reuse get_config_info(), while preserving the configuration name, type, and mutability fields.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason: The change is limited to replacing one sensitive configuration value at the shared output point. clang-format, git diff --check, and config.cpp compilation passed.

• Behavior changed:

  • No.
  • Yes. tls_private_key_password is now returned as ****** instead of its plaintext value.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?