rpc: fix multi-entry responses for getLedgerEntries method

[2opremio]

Closes #1084

The key->entry correspondence was broken since the code assumed a 1-to-1 match (in size and ordering) between the keys in the request and the keys in the response.

This didn't hold because:

1. Some keys may be missing in the response (if not found in the db).
2. The db access method (LedgerEntryReadTx.GetLedgerEntries()) returned a result whose ordering wasn't consistent with its arguments (due to traversing a map to build the result).

This change:

1. Fixes the key->entry mapping
2. Makes getLedgerEntries response ordering stable and consistent with the keys provided.
3. Make a few small performance improvements (mostly allocation related) along the way.
4. Increases test coverage.

[2opremio]

Overrides #1084

[Shaptic]

Awesome! Thanks fons 👏

Two logistical questions:

• Do we typically add changelog entries in PRs or are they summarized as part of the release?
• Should this be targeting rc.4.2 so we can release it to testnet?

[2opremio]

Awesome! Thanks fons 👏

Two logistical questions:

* Do we typically add changelog entries in PRs or are they summarized as part of the release?

We don't even have a CHANGELOG file. It seems tsachi has been using github releases as a changelog.

But ... we could change that if you think it's better.

* Should this be targeting `rc.4.2` so we can release it to testnet?

Uhm, we can do it if necessary.

But ... the XDR and symbol names have considerably diverged from what's on testnet since #1029 , so I am not sure it's worth it.

The bug is pretty horrible though, but I think it has gone unnoticed until because most people do single key requests.

[Shaptic]

@2opremio agreed with your point about divergence! Let's merge to main for now. And we can keep it in the release notes for now, but we should start a changelog once we have a stable release imo 👍

I'll look into cherry picking it afterward: this has bigger effects because of the workaround @sreuland added in stellar/js-soroban-client#161 so that users can get expiration data after it moved into its own entry, so most requests will have 2 keys 😅 if it's too messy I'll just abandon it