ingest/ledgerbackend: Add core configuration support for BUCKETLIST_DB_MEMORY_FOR_CACHING

[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 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

Fixes #5600

Disable BUCKETLIST_DB_MEMORY_FOR_CACHING by default in the captive core library. The BUCKETLIST_DB_MEMORY_FOR_CACHING configuration field was introduced in stellar-core version 22.2.0 so we can only apply the default when running a core binary with that version or higher. If we include BUCKETLIST_DB_MEMORY_FOR_CACHING in a core toml file for an older version of core, stellar-core will crash because it will not recognize the configuration field.

Why

In an upcoming core release, the default value for BUCKETLIST_DB_MEMORY_FOR_CACHING will be increased to potentially 3GB. If we omit the BUCKETLIST_DB_MEMORY_FOR_CACHING field in our captive core toml files then operators will see a sudden increase in memory usage by 3GB due to the BUCKETLIST_DB_MEMORY_FOR_CACHING configuration. This extra memory is useful for validators but it is not a useful optimization for watcher nodes.

Known limitations

[N/A]

[Shaptic]

I hate that we have to version parse, but this is as clean as it gets if we're gonna do that.