C backend: Adjust typeCBop() to not rely on FB_DATATYPE_* order
C backend: Don't emit casts between compatible integer types (integer/long)
compiler: Fix setjmp() declarations
C backend: Disable hDoOptRemConv()
compiler: Rename FB_USE_FUNCMODE_FBCALL to FB_FUNCMODE_FBCALL
C/LLVM backends: Ignore calling conventions when emitting non-x86 code

On x86 we support stdcall/cdecl/pascal, but x86_64 (or ARM for that matter)
doesn't have these calling conventions. On x86_64 there is only one
calling convention (per system; the one used on Windows x64 is different
from the one used on 64bit Linux).

64bit MinGW simply ignores stdcall/cdecl/fastcall attributes and uses its
default calling convention for everything. GCC for x86_64 Linux or ARM
does the same, and shows warnings about it.

This shows that on x86_64 we cannot support stdcall/cdecl/pascal, even
though it would probably be technically possible with an x86_64 ASM
backend.
- but, we have no x86_64 ASM backend
- gcc doesn't support it, so -gen gcc couldn't support it
- LLVM also ignores x86_stdcallcc/x86_fastcallcc when compiling with
  llc -march=x86-64, and uses the 64bit calling convention everywhere,
  so -gen llvm couldn't support it either
- and since the C compilers don't support it, most likely nobody uses
  stdcall or cdecl on 64bit anyways

That only leaves these options for FB:

a) Disallow STDCALL/CDECL/PASCAL keywords on x86_64/ARM, to show that
   these calling conventions are not supported. However, this would
   require all code using the keywords to be adjusted to compile for
   non-x86 using #ifdefs. For example, FB's own test suite uses CDECL
   everywhere to be compatible with the CUnit library. If CDECL was
   disallowed, we'd have to add #ifdef __FB_64BIT__ everywhere to compile
   in the function declarations without CDECL for 64bit, but ones with
   CDECL for x86...

b) Ignore STDCALL/CDECL/PASCAL keywords completely, like gcc.
   This solves the problems with a), but it would allow things like
	sub f cdecl( )
	end sub
	dim p as sub stdcall( ) = @f
   to go unnoticed, while it's incompatible pointers on x86.

c) Handle calling conventions on the compiler level as always, showing
   incompatible pointer types warnings on x86_64 as would be done on x86,
   but ignore calling conventions when emitting non-x86 code. This seems
   like the best solution to me.
Adjust C++ name mangling for 64bit