Precedence issues between unary byte/word-access operators and postfix increment/decrement

[Bananattack]

Currently all postfix operators have higher precedence than prefix operators. This has some unfortunate limitations though:

// Postfix increment in expression statement. Fails to compile.
// because it is evaluated as <:(hl++), which is not a permitted expression statement.
// Also because of precedence, it also currently implies a higher-bit increment followed by bit-masking.
<:hl++;

// Postfix increment in assignment right-hand side. Also fails.
// Similar to above parse, but different restrictions.
// It tries to decompose <:(hl++) into:
// a = hl; a = <:a; hl++; which will not work.
a = <:hl++;

++<:hl; // Prefix increment. Works fine.
a = ++<:hl; // Prefix increment. Works fine.

See if there's some way that the compiler can instead bind the unary prefix access operators with less precedence than incrementation (eg. by manual fix-up during parsing). Most of the time, we want normal prefix operator precedence rules, but post-incrementation is an exception.

Short of some other ambiguity, it would be nice to make <:expr++ always mean (<:expr)++ and not >:(expr++) so it has more useful semantics.

NOTE: these uses should continue to work:

// becomes a = l; due to register decomposition.
a = <:hl;
// take the low-byte of an address literal.
a = <:&myaddress;
 // constant indexing, so the address can be folded at compile-time, and then <: masks off
a = <:word_array[0]
// take the low-byte of some indirected larger-than-byte thing (if the platform were to allow it)
foo = <:*term;