ingest/ledgerbackend: new captive core toml config parameters

[sreuland]

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 reviewed the changes in this PR and if I consider them worthwhile for being mentioned on release notes then I have updated the relevant CHANGELOG.md within the component folder structure. For example, if I changed horizon, then I updated (services/horizon/CHANGELOG.md. I add a new line item describing the change and reference to this PR. If I don't update a CHANGELOG, I acknowledge this PR's change may not be mentioned in future release notes.
• 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

Added new captive core toml config parameters to CaptiveCoreTomlParams:

• EmitUnifiedEventsBeforeProtocol22 setsENABLE_BACKFILL_STELLAR_ASSET_EVENTS
• EmitVerboseMeta convenience flag, when set to true it will enable all config flags related to emitting more verbose transaction metadata: ENABLE_SOROBAN_DIAGNOSTIC_EVENTS, ENABLE_DIAGNOSTICS_FOR_TX_SUBMISSION, ENABLE_EMIT_SOROBAN_TRANSACTION_META_EXT_V1, ENABLE_EMIT_LEDGER_CLOSE_META_EXT_V1, ENABLE_EMIT_CLASSIC_EVENTS, ENABLE_EMIT_CLASSIC_EVENTS

Why

give clients the ability to toggle on/off the verbosity of meta generated in their captive core ledger metadata.

Closes: #5719

Known limitations

[Shaptic]

Not a huge fan of the name EmitUnifiedEventsBeforeProtocol22 but can't think of something better that doesn't have misimplications lol. LGTM!

[Shaptic]

You might be out of date with the base branch @sreuland, #5755 has the fix for the failing test. Imo it's okay to merge so I can pick it up downstream.

[sreuland]

You might be out of date with the base branch @sreuland, #5755 has the fix for the failing test. Imo it's okay to merge so I can pick it up downstream.

@Shaptic , thanks for heads up, I will let this run just a bit further on integration tests to confirm and them merge.