rtlib: Delete empty module
ast: Preserve DEREF's dtype when optimizing ADDROF(DEREF(x)) to x
Fix CHttpStream.bas
Was doing a 'string = *byte ptr' assignment, which has been disallowed now.
Cast to zstring ptr first for same effect.
makefile: Remove unused AS variable
makefile: Fix reference to fbc-new
makefile: Rename *.o dir variables to use more sensible names
makefile: Assume mkdir -p works

The makefile isn't trying to be compatible to mingw32-make/cmd.exe for
a long time now, so it may aswell make use of mkdir -p which is
available under Linux, MinGW/MSYS, and also DJGPP.
Revert "rtlib: Rename fbinteger to fbint"

This reverts commit f1302be50ed03ee08e24376ae92a7ca54cb8fe3a.
Revert "rtlib: Adjust array functions to use fbinteger"

This reverts commit e8444610603851d8a32b2adecad355360c8fbc25.
astNewBOUNDCHK(): Assume both l/ubound are CONST if one is
Merge branch 'master' into 64bit

Conflicts:
	src/compiler/ast-node-check.bas
rtlib: Switch to ssize_t/size_t instead of fbint/fbuint

- It's too much work to change the entire rtlib/gfxlib2 to use custom
  typedefs everywhere.
- A lot of "int" can stay "int", don't need to become 64bit, e.g. error
  codes or x/y coordinates.
- A lot of rtlib code already uses size_t, no changes needed there.
- It's good to use "native C" data types like size_t, instead of custom
  ones.

This way the amount of changes needed, especially to system-specific code
like printer or serial I/O, will be much smaller. Thus there will be much
less unnecessary changes obfuscating the diff.
rtlib: Move fb_hDevFileSeekStart() declaration into header
rtlib: Move fb_FileInput() declaration into header
rtlib: Rename fb_ConsoleInput()'s module
Merge branch 'master' into 64bit
rtlib: Change lots of lengths/counts/sizes ints over to ssize_t/size_t
rtlib Print Using: Change several longs to ints

It looks like these were intended to be 32bit so int should be used as
long changes to 64bit on 64bit Linux.
gfxlib2: Change several ints over to ssize_t
compiler: Only declare/use fb_CpuDetect() on x86

Currently I still see now point of having it for x86_64, as there
doesn't seem to be a need to check for CPU features there.
Perhaps that will be different for other architectures like ARM?