Fix various parameter cycling loops that could break with PASCAL procedures

closes: #621

For the PASCAL calling convention, arguments are pushed in the declaration
order, not reversed like CDECL/STDCALL. This affects the order of ARG
nodes in CALLs, and it affects the C/LLVM backends' code generation,
but that's it.

It should affect neither the parsing of argument lists nor overload checks
on the FB side. However exactly that was happening due to mis-use of the
symbGetProcLastParam() and symbGetProcPrevParam() macros, which would walk
from head to tail through the next links for CDECL/STDCALL procedures,
but walked from tail to head through the prev links for PASCAL procedures,
thus breaking any code that checked the arg being parsed against the param.

For example, cProcArgList() (and also hOvlProcArgList()) use the param
to check for BYDESC:

	declare sub f pascal( a as integer, b() as integer )

	dim array() as integer
	f( 123, array() )

Since "f" is PASCAL here, the parameter list was walked in the wrong order,
causing cProcArgList() to see the 1st arg "123" as param "b", and the
2nd arg "array()" as param "a". Since param "a" isn't BYDESC, the bydesc
array parentheses were disallowed, causing the issue seen in bug #621.

At least astNewARG() would later detect any type mismatches (including
passing "123" to bydesc array param "b", so this also results in a compiler
error:

	f( array(), 123 )

The same problem existed in symbFindClosestOvlProc() which prevented
PASCAL proc overloading from working properly.

Additionally astReplaceARG() (now renamed to astReplaceInstanceArg()) also
didn't handle PASCAL properly, causing it to replace the wrong ARG.