make unary prefix operators bind tighter than the as/is cast

[Cintu07]

found a precedence bug: *p as int parses as *(p as int) instead of
(*p) as int, so dereferencing through a cast doesnt compile:

var x: int32 = 42;
let p = &x;
return *p as int;   // error: '*' (dereference) applied to non-pointer type 'int'

(*p) as int works, and *p on its own works, only the combo breaks. same thing
hits -, ~, !, & in front of a cast. the parser ladder had ParseCast below
ParseUnary so the cast bound tighter than the prefix ops.

reordered it to ParseExp -> ParseCast -> ParseUnary -> ParsePostfix so the prefix
applies first, matching the usual precedence and the pointer examples in the
docs. chained casts, casts as binary operands, and ** are unchanged, and the
existing io/pow/unicode suites still pass.

added Tests/CastPrecedence + run_cast_precedence_test.sh, wired into all 3 CI
workflows.

[musicvano]

I encountered this problem. Let's create a poll on the Discord server. We should define the priority of the as keyword. Because it impacts on the source code.
a + b as int8 is it (a + b) as int8 or a + (b as int8)?

[Cintu07]

yeah worth pinning down. one scope note first: this PR only changes the
unary-vs-as level (*p as int -> (*p) as int). the a + b as int8 case is a
different level (as vs +), and it already parses as a + (b as int8) today,
before and after this PR. confirmed with --dump-ast:

a + b as int8
BinaryExpr +
IdentExpr a
CastExpr as int8
IdentExpr b

so rux already matches rust here: unary binds tighter than as, and as binds
tighter than the arithmetic ops:
*p as int -> (*p) as int
a + b as int8 -> a + (b as int8)

my vote is keep it as-is, matches rust/c and is the least surprising. are you
putting the poll up, or do you want me to run it on discord? happy either way.

[pascalecu]

The poll concluded just now, and the final decision is to parse a + b as uint8 as (a + b) as uint8.

[spatulari]

please resolve the conflicts.

[Cintu07]

okok i will, sorry for late respomse

[yydev-official]

I this more of a quality of life merge?

[Cintu07]

The poll concluded just now, and the final decision is to parse a + b as uint8 as (a + b) as uint8.

this PR only changes the unary-vs-as level
(*p as int -> (*p) as int), it doesnt touch where as sits relative to + and *,
so the poll result (a + b as int8 -> (a + b) as int8) is a separate change.

happy to do that one too. one thing to settle first, if as just becomes looser
than +, then a as int8 + b stops parsing (the + b gets orphaned, youd need
parens). cleanest fix that gives the poll result without breaking that is to put
as at the same precedence as the additive ops, left associative:
a + b as int8 -> (a + b) as int8 (poll)
a as int8 + b -> (a as int8) + b (still works)
want me to fold that into this PR or open a separate one so this stays scoped to
the unary fix? also rebased, conflicts are resolved

[Cintu07]

I this more of a quality of life merge?

its a bug fix, not just QoL. right now p as int doesnt compile at all, it errors
"'' (dereference) applied to non-pointer type" because it parses as *(p as int).
same for -x as T, ~x as T and so it unblocks real code

[pascalecu]

Right now this has merge conflicts. Could you rebase on dev, convert your test to the new format (i.e. Test.cmake instead of *.sh) and undo your changes in the workflows (as now it all goes through ctest)? Otherwise, the code looks good, I'll merge it if you apply the aforementioned suggestions. @Cintu07

[pascalecu]

See comment above.

[Natuworkguy]

I resolved the conflicts

[spatulari]

building doesn't work on linux, macOs and Windows, please fix