`int64` Precision Issues

**Is your feature request related to a problem? Please describe.**
Some blockchain teams have noted that precision may be lost for `int64` numbers in some clients (like JS) if a number greater than `2^53` is populated since JSON defines numbers as `float64`.

Example (`BlockIdentifier`): https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/models/BlockIdentifier.yaml#L22-L27

**Describe the solution you'd like**
Unfortunately, `int64` is [highest precision number type](https://swagger.io/docs/specification/data-models/data-types/#numbers) you can specify in OpenAPI (also not possible to use `uint64`). To remedy this issue, we would need to encode all `int64` numbers as `string`.

Fortunately, this issue only will affect `BlockIdentifer.Index` and `Block.Timestamp` as all other "number-like" values that could come close to `2^53` are already encoded as strings (ex: `Amount.Value`). `Operation.Index` (which is also encoded in `int64`) shouldn't run into this issue as it is relative to the `Transaction` where an `Operation` is present in, not a global index.

Start with models/BlockIdentifier.yaml at the linked Index definition, then locate the Block.Timestamp and Operation.Index model definitions. Check how these int64 fields are represented in the specification and identify the affected generated or validation artifacts. Done means BlockIdentifier.Index and Block.Timestamp are encoded as strings while Operation.Index and existing string-encoded values remain unchanged.

Written by the indexing model from the issue text.