rtlAddIntrinsicProcs(): Don't change proc data, it's needed for later runs

rtlAddIntrinsicProcs() must not modify the RTL procedure definition tables,
as they may be needed for later runs, when compiling multiple modules in
the same fbc invocation.

The main issue was that the code changed the ALIAS field of the procedure
defintions, for RTL procedures that didn't have ALIASes yet.

The main code path (-lang fb/fblite, or -lang qb for procedures without
'__' prefix) only changed it to point to the same string as the name field,
which is no problem because the name field is unique to each procedure
definition anyways.

However, the code path for -lang qb and procedures with '__' prefix
changed it to point to STATIC STRINGs, which would result in all such
procedures pointing to the same STATIC STRING in the end. This then breaks
all further runs of rtlAddIntrinsicProcs() because the ALIAS fields of
these functions are no longer NULL. Instead they're all pointing to the
same STATIC STRING, and all ended up being declared using that ALIAS.

This problem seems to have existed since 6f2c7374.

In older FB versions (0.23) there are only two functions that have the
FB_RTL_OPT_NOQB flag (for the '__' prefix under -lang qb) and don't have
an ALIAS set in the RTL procedure definition tables: fb_WstrRset() and
fb_GfxImageCreateQB(). That explains why this issue wasn't discovered
earlier - it didn't affect many functions at all.

The following test case shows the problem in FB 0.23 already:
	1.bas
		dim image as any __ptr
		image = __imagecreate( 32, 32 )
	2.bas
		dim image as any __ptr
		image = __imagecreate( 32, 32 )
	compiled as:
		FreeBASIC-0.23.0-linux/fbc 1.bas 2.bas -lang qb -R
by examining the resulting 1.asm and 2.asm, we see that 1.asm calls
fb_GfxImageCreateQB() as expected, but 2.asm calls fb_WstrRset() instead.
This causes a linker error on Win32 thanks to the @N stdcall suffix, but
is silently accepted on Linux.

In current FB there are more functions with the NOQB flag and without an
explicitly specified ALIAS in the RTL procedure definition tables:
	fb_WstrRset         (unchanged)
	fb_ThreadCall       (ALIAS removed since 71a24e00)
	fb_MKSHORT          (ALIAS removed since 50bc6bc9)
	fb_MKLONGINT        (ditto)
	fb_GfxImageCreateQB (unchanged)

This caused the issue to show up with previously working programs:
	http://www.freebasic.net/forum/viewtopic.php?f=17&t=21671
Test case:
	1.bas
		x$ = mki$(0)
	2.bas
		x$ = mki$(0)
	compiled as:
		fbc 1.bas 2.bas -lang qb -R
1.asm calls fb_MKSHORT() as expected, but 2.asm calls fb_MKLONGINT().
As above, on Win32 this causes a linker error thanks to the @N stdcall
suffix but is silently accepted on Linux.

I'm not sure how these test cases could be added to the FB test suite,
as they are pretty specific about how they must be compiled to trigger
the problem, so they're here for now.
fb.bas:hAppendFbctinf(): Remove unused variable