ingest/ledgerbackend: Refactor captive core process manager

[tamirms]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

Refactor stellarCoreRunner to fix the following issues related to process termination and leaking of resources like goroutines:

#5349
#5342
#5347

Known limitations

[N/A]

[2opremio]

Really nice! I am looking forward to test it in soroban RPC!

[urvisavla]

it's really nice to have split the code into multiple files such as catchup.go, runfrom.go etc, but since the ledgerbackend directory is not only for the captive-core ledger backend. Do you think it makes sense to either group all the captive-core ledgerbackend-related files into another subdirectory within ledgerbackend directory or prefix the file names with "captive-core" (though shorter file names are preferable)? This also applies to some of the existing files such as toml.go etc.

[tamirms]

@urvisavla I think every file in the ledgerbackend directory is related to captive-core except for the code which implements and tests the BufferedStorageBackend . I'm reluctant to create a separate package for captive-core because that would require all users of captive-core to update their import paths