ast: Fix astCanTakeAddrOf() to handle LINK nodes
Fix WITH + function results returned in registers (Win32 only)
parser: Fix ASTNODE leaks when optimizing WITH/SELECT with plain variables
ast: Add functions to determine the effective/result node in a LINKed tree

As an alternative to the astIs*() macros, these new functions should help
detect an expressions AST node class, while handling LINKs.

For example, given the following AST:
	LINK(DECL, VAR) with LINK.ret_left = FALSE
it's a LINK node with lhs pointing to a DECL and rhs pointing to a VAR.
The LINK returns the rhs because its ret_left property was set to FALSE.

Thus, the AST effectively is a VAR, as least from point of view of things
like the  expression type or expression data type checks in the parser.

However, astIsVAR() would return FALSE, because the toplevel node is a
LINK, not a VAR. Hence we need the new functions which walk the LINKs.
astGetEffectiveClass() would tell us that it's a AST_NODECLASS_VAR though,
as expected.

I think a lot of code in the compiler would benefit from being switched
over from astIsVAR() & co to the new functions, either as optimization,
fixing bugs, or simply removing quirks.

For example, WITH and SELECT currently use astIsVAR() to determine whether
to create a temp var or not. If they're given a VAR already then they don't
need to create a temp var. However, due to astIsVAR() not walking LINKs,
they'd misdetect such cases where the expression is a LINK which
indirectly is a VAR. Thus, at least, by being switched to the new function,
we could avoid unnecessary temp vars.
ast: Add astRebuildWithoutEffectivePart()
WITH/SELECT: Avoid unnecessary temp var in case of LINKed expression