[fix](tool) Fix meta_tool coredump and dead loop issues

[wenzhenghu]

What problem does this PR solve?

related issue：#61447

Proposed changes

This PR fixes several bugs in the offline tool meta_tool, including coredumps caused by uninitialized ExecEnv components and a dead loop when loading tablet meta.

1. Fix coredump in offline commands:

   • For lightweight commands (show_meta, batch_delete_meta, show_segment_footer, show_segment_data): These do not require a full StorageEngine environment but still rely on basic components like TabletSchemaCache, TabletColumnObjectPool, and MemTracker. This PR introduces a lightweight initialization function init_common_components() for them to prevent coredumps caused by null pointer dereferences.
   • For engine-level commands (get_meta, load_meta, delete_meta): These commands initialize a StorageEngine and DataDir instance to read/write RocksDB. The PR ensures that they correctly load configurations from be.conf (via DORIS_HOME) and also call init_common_components() to guarantee that both the global settings (e.g., memory limits, thread pools) and the ExecEnv components are properly set up before the engine starts.

2. Fix dead loop in load_meta:
   The TabletMetaManager::load_json_meta function previously used infile.getline() in a while(!infile.eof()) loop. If the file cannot be opened or an error occurs, the failbit is set but not the eofbit, causing an infinite loop. This has been fixed by reading the file content safely using std::istreambuf_iterator and adding an is_open() check.

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

• Behavior changed:

  • No.
  • Yes.

• 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?

[wenzhenghu]

run buildall