Prefix all defines in hl.h with `HL_`

[tobil4sk]

The majority of macros in hl.h already follow this rule, however, there are a few that don't, in particular type names for ffi:

hashlink/src/hl.h

Lines 824 to 848 in fbfedd8

	#undef _VOID
	#define _NO_ARG
	#define _VOID "v"
	#define _I8 "c"
	#define _I16 "s"
	#define _I32 "i"
	#define _I64 "l"
	#define _F32 "f"
	#define _F64 "d"
	#define _BOOL "b"
	#define _BYTES "B"
	#define _DYN "D"
	#define _FUN(t, args) "P" args "_" t
	#define _OBJ(fields) "O" fields "_"
	#define _ARR "A"
	#define _TYPE "T"
	#define _REF(t) "R" t
	#define _ABSTRACT(name) "X" #name "_"
	#undef _NULL
	#define _NULL(t) "N" t
	#define _STRUCT "S"
	#define _GUID "g"
	#undef _STRING
	#define _STRING _OBJ(_BYTES _I32)

In C, identifiers beginning with an underscore and an uppercase letter are reserved, so it is not a good idea to be using these. This is why the #undef hacks are needed for _NULL, _VOID and _STRING, and why #undef _GUID is required in some cases after including hl.h: #748 #804.

It would be good to gradually transition to names that aren't reserved and preferably names prefixed with HL_. This can be done by providing both defines for now and marking the current ones as deprecated, and adding a flag to turn off the old definitions.

This not only avoids the use of reserved identifiers, but it also makes it easier for the hlc generator to check haxe identifier clashes with hl.h macros. It can simply assume that anything starting with HL_ needs to be mangled, rather than having to be aware of all the types defined by hl.h. Related issue: HaxeFoundation/haxe#11419

(As a sidenote, the type name macros are only required for building hdlls, and not in hl vm code or in hlc programs, so it might be worth considering moving these to a separate hl_ffi.h header.)