Adding fix to process 64 bit integers correctly.

[davidcho23]

Currently, the valid 64 bit integer -9,223,372,036,854,775,808 is treated as an invalid integer.

This is because for a negative integer, a unary operation token is created for the minus sign and an integer token is created for the integer. This integer token value is always positive.

When validating the integer value is within the range of a 64 bit integer, -9,223,372,036,854,775,808 fails because its integer token has a value of 9,223,372,036,854,775,808 and is greater than the max 64 bit integer 9,223,372,036,854,775,807.

Many approaches were thought of such as:

• Looking at what the Roslyn compiler does which is lexing"-123" as two separate tokens then checking for overflow later on. It didn't feel like a good idea to start lexing "-123" as a single token.
• Handling in the parser would add complexity because you only want to check for the overflow after you've seen the full number.
• Providing negative and positive range checks in the TypeAssignmentVisitor, which would work if you shortcut in the VisitUnaryOperationSyntax() method to not touch VisitIntegerLiteralSyntax() method. However, this could cause other things to break because this means a type check is forced on the syntax being shortcut.

Finally, the only appropriate way thought of to handle this issue would be to create a dedicated visitor in the emit limitation calculator, which is after type checking. Here, we can choose to shortcut the syntax without affecting other processes such as type checking.

Fixes #5324

[miqm]

Hello, please follow the contribution guide and include reference to the issue you're fixing. Also, please correct your PR so for tests to pass.

[anthony-c-martin]

Looks great! Just had a few comments to look over

[anthony-c-martin]

Looks great!

[shenglol]

Looks great!

[majastrz]