feat: add support for unsigned integer MIN and MAX type bounds

[metalurgical]

Introduce parser support for unsigned integer constants (MIN, MAX) across all variants.

Can be further extended easily to include other type specific constants like ZERO, ONE, etc in future.

Extensible for future types that need specific constants as well, without interfering with existing constant types.

[metalurgical]

Resolves #252
Closes #252

[KyrylR]

Thanks for the contribution!

Overall it LGTM, but there is a nuance with errors

[KyrylR]

So now with this example:

fn main() { let pk: Pubkey = witnes::PK; }

Error changed from:

Expected ';', found '::'

to things like:

Expected unsigned integer type before ::
Expected MIN or MAX after unsigned integer type

[KyrylR]

[metalurgical]

So now with this example:

fn main() { let pk: Pubkey = witnes::PK; }

Error changed from:

Expected ';', found '::'

to things like:

Expected unsigned integer type before ::
Expected MIN or MAX after unsigned integer type

Thanks for pointing this out. +1

[KyrylR]

Nevertheless, would like to hear your opinion on this

[metalurgical]

Nevertheless, would like to hear your opinion on this

I had incorrectly assumed this case would have been caught by existing tests. Additional tests have been added around this and corrected the implementation here.

[KyrylR]

ACK bbf4cbc; code review

[KyrylR]

just for context, waiting for the second review before merging

[stringhandler]

Long time, Strider, I hope you are well. I think it would actually be better to model this properly. It's a Const or a Call at best, rather than a new unique language feature. I would rather say we should treat it as an Ident on the lexer, a Constant(ConstantName) on the parser and AST level, kind of how we do Call. It could maybe even be written as a call.

[metalurgical]

Long time, Strider, I hope you are well.

@stringhandler It has been and likewise.

I think it would actually be better to model this properly. It's a Const or a Call at best, rather than a new unique language feature. I would rather say we should treat it as an Ident on the lexer, a Constant(ConstantName) on the parser and AST level, kind of how we do Call. It could maybe even be written as a call.

The current approach was intentionally limited to address the immediate issue with minimal changes, while leaving room for future extension if needed.

I agree that modelling this as part of a more general language construct would be both sound and a cleaner long-term solution.

The current approach is contained such that it does not prevent transitioning to that model in future.