[Enhancement] Expose jemalloc runtime options as be config (backport #75344)

[mergify]

Why I'm doing this:

The jemalloc runtime options used by BE/CN are currently set only as the JEMALLOC_CONF environment variable inside bin/start_backend.sh. Because information_schema.be_configs is populated purely from config::list_configs() (i.e. items declared in be/src/common/config.h), this value is invisible there — there is no way to confirm via SQL which jemalloc options a running BE/CN was started with.

What I'm doing:

• Add a new BE config jemalloc_conf (CONF_String, immutable) in be/src/common/config.h, defaulting to the normal-mode jemalloc option string. This makes the value queryable through information_schema.be_configs.
• In bin/start_backend.sh, the normal startup path (neither --jemalloc_debug nor --check_mem_leak) now reads jemalloc_conf from be.conf/cn.conf and exports it as JEMALLOC_CONF, falling back to the built-in default when unset. The --jemalloc_debug and --check_mem_leak modes keep forcing their own JEMALLOC_CONF values and ignore the config, as before.

Note: jemalloc reads JEMALLOC_CONF during process init, before BE config parsing, so this config does not reconfigure jemalloc at runtime — it serves as the single source of truth for the startup script and for observability. The script default and the config.h default are kept in sync (commented in both places).

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5

---

This is an automatic backport of pull request #75344 done by [Mergify](https://mergify.com).

[github-actions]

No new undocumented parameters detected by the param-drift check.