fix: repair i128 typed data encoding and add typed data range checks

[penovicp]

Motivation and Resolution

Resolves #1002 (i128 typed data encoding). Also adds typed data range checks for primitive types and a "StarkNet" casing update for typed data types.

Usage related changes

The encoding changes should not affect users that use valid data, if the data is outside the permitted range it will generate errors with the code from this PR. If users are using some of the updated types they will need to update them to their new name.

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Linked the issues which this PR resolves
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[penovicp]

I want to draw attention to the approach taken with the shortstring encoding. It was implemented by reusing the existing felt encoding.

As a basic example, a provided value "hello" will be encoded as 0x68656c6c6f, this I believe to not be contentious. The part where I believe there might be issues with is the encoding of numerical strings, the existing felt encoding treats both numbers and numerical strings as the same value and such behaviour might be undesirable/unexpected for the shortstring type. As an example "2" will be encoded as 0x2 while someone coming from a Cairo background will probably assume it to be encoded as 0x32.

[tabaktoni]

IGWT!