Re-enable optimisation that caused bug #2099245 (now feature request #191).
The bug shouldn't occur now, since more consistent type promotion is done, but add
but add an additional check just in case
Merge remote-tracking branch 'origin/master'
wx-c headers: Fix wxStyledTextCtrl_StyleSetSize() declaration

(patch by St_W/MOD)
Add 64x64 and 200x200 versions of the FB logo/icon
Fix indentation on my previous change (e7de49a) - I didn't mean to commit it at the time.
Add unit test for each added op, plus '\' (just to make sure its operands are never swapped)
astNewVAR(): Create proper subtype symbol for function pointers

instead of just using the procedure itself, which can cause problems with
the C backend when emitting, because a procedure name isn't a valid data
type. The C backend relies on function pointer PROC subtypes to be emitted
as typedefs, but of course doesn't do that for normal PROCs. This can
happen for code that derives variable data types from an @proc expression,
such as the temp vars created for passing an rvalue expression such as
@proc to a BYREF parameter.

This change means that astNewVAR() can now create new symbols, and that
also required symbCloneSymbol() to be adjusted to handle procptr subtype
symbols, because they can appear inside AST temp scopes now (such as
TYPEINIs, see also the astTempScope*() functions).
tests: Add test case for function pointer expression subtraction

http://www.freebasic.net/forum/viewtopic.php?f=3&t=21356

Following up with the previous commit: Creating the proper procptr subtype
symbol will now also let it be re-used for function pointers with the same
type in the same scope, even if they were based on a different procedure.

That's how it should be, because type checks such as for pointer arithmetic
in astNewBOP(), compare the subtype by address. Where previously an
expression like @sub1 - @sub2 was refused because the subtypes were
different (pointing to the PROC symbols for sub1 and sub2 respectively),
they will now be mapped to the same procptr subtype symbol, and astNewBOP()
will accept the expression.
Disallow procedure pointer arithmetic

because it doesn't make sense. Previously, procedures were treated as
being 4 bytes in size in the context of pointer arithmetic
(symbCalcDerefLen() and its callers), but that's useless.
Doing +1 (or rather, +4) on a procedure pointer doesn't take it to the
next procedure. Same goes for subtraction of function pointers.
Furthermore, sizeof() doesn't work on functions...
parser: Ensure to preserve CheckArray flag properly

Whenever adjusting expression parser flags, the original state must be
restored afterwards, to not break the overall parser state.

27c1b790 introduced some bad fbSetCheckArray() calls in array index
parsing, which from then on trashed the parser state. The same problem
existed in typeof/sizeof expression parsing.

http://www.freebasic.net/forum/viewtopic.php?f=3&t=21367
Fix several off-by-ones in ON GOTO jump table generation
Update changelog

64bit support based on -gen gcc is close to finished. The big chunks of
work are done:
- deciding on INTEGER=32bit/64bit, LONG=DWORD
- adjusting the compiler internals to remove most x86 assumptions
- adjusting the rtlib to use [s]size_t instead of int where needed,
  e.g. FBSTRING's length field
- adjusting the compiler's rtl-* function definitions accordingly
- adjusting the makefile and compiler frontend to support compiling
  for x86_64

As of now, FB can build a hello world program for x86_64 Linux and Windows,
although the compiler cannot rebuild itself for x86_64 yet.
Merge branch 'master' into 64bit

Conflicts:
	src/compiler/symb-data.bas