[hldx] Implement Drag&Drop api

[Yanrishatum]

Adds D&D support for DirectX in a similar fashion to hlsdl. There are some caveats thought.
Small note on buffer formatting: SDL implementation requires String.fromUTF8 (since SDL buffer is UTF8) to convert the buffer into Haxe String. DX needs String.fromUCS2 as it's raw DragQueryFileW buffer output.

Big note on GC shenanigans:

Due to the fact that events are queued and consumed asynchronously - string buffers of dropped files are added to gc root, as well as require extra checks on event type when consuming events/destroying window. This is mandatory, because when buffer is not rooted - if GC runs in any circumstance - we get garbage data on event consume stage. And extra checks on type are here to ensure there's no gc root memory leaks.

This could be alleviated if dx_event* array was properly GC-managed list of dx.Event instances instead of data storage that is being memcopy'd on consumption. But that would require pretty substantial rewrites and breaking changes.

Additionally, haxelib.json versions of both hldx and hlsdl were bumped. I also would like to note that it's better to decouple those versions from HL version as to make it much easier to add new features when working with nightly HL, and not needing to hack into hl_ver or writing code that won't work on current HL version but will on next HL release that happens who knows when.

[ncannasse]

I think adding/removing roots is not the best solution here in terms of performances. Maybe you should alloc C memory in WM_DROPFILE then in events processing alloc GC memory as a copy of C data then free() the C memory ?

[Yanrishatum]

Done.

I still think that HL needs an API that lets HL code to obtain hl_type* pointers of Haxe-side classes without resorting to crude hacks like DX of memcpy of idential structure or hlimgui hijacking them from dummy instances passed to it on init time.

This would allow to properly allocate things like dx.Event instances from C side and storing them in custom GC root related the window, and returning said instances instead of doing memcpy into Haxe-side allocated reused instance.

I already made a proof of concept that works in HL/JIT, but I'm not confident it'd work on HL/C.

[ncannasse]

@Yanrishatum you can already allocate on C side without having an hl_type by using @:struct class X {} that does not carry the type.

[Yanrishatum]

@ncannasse Is there a way to allocate those as GC-managed, thought? Additionally, it doesn't resolve issues of allocating things that are not user-accessible, like std classes. For example directly allocating String instead of passing byte data to Haxe and doing internal methods to convert it into a String.

[ncannasse]

Well yes you can simply allocate using (mystruct*)hl_gc_alloc_raw(sizeof(mystruct)) (or gc_alloc_noptr if it doesn't contain any gc pointer)