Add back in Protocol 22 non-breaking changes for a transition period

[Shaptic]

What

This PR smooths out the breaking changes to Stellar RPC's API to make it possible for users to upgrade SDKs without experiencing breakage. Namely,

• Previously, in RC2, getTransaction would encode createdAt as a string instead of number. This change has been reverted. We will continue to encode it as a number (specifically, a uint32).
• Previously, getEvents replaced pagingToken with cursor within each event for pagination. This change is now additive, and the response schema will now include both fields.
• Previously, getVersionInfo would now use camelCasing over snake_case. This change is now additive. The response schema will contain both variants:

interface GetVersionInfoResponse {
  version: string;
  commitHash: string;
  buildTimestamp: string;
  captiveCoreVersion: string;
  protocolVersion: number; // uint32
  /// Deprecated field names:
  commit_hash: string;
  build_timestamp: string;
  captive_core_version: string;
  protocol_version: number; // uint32
}

Why

When a user upgrades to the latest version of your SDK, their code will now only be compatible with a v22.* version of the backend services they're connected to. This means they can only upgrade exactly when their RPC/Horizon provider upgrades, which is a violation of the previous compatibility guarantees we provide the ecosystem.

A concrete example: someone with an existing codebase may have code written that uses the createdAt field returned by rpc.getTransaction. If they upgrade to the latest version, their code will break because the field is now strictly typed as a string. And yet, if they were to update their code accordingly, their code would not function unless they pointed at a v22 RPC. This is the lockstep upgrade we are trying to avoid. This is in contrast to a change like cost being removed, because they can write code that works on both v21 and v22 RPCs by using the existing transactionData field to migrate.

This PR smooths those things out.