Add heaps_disable_res_completion compilation flag

[Yanrishatum]

Adds a heaps_disable_res_completion compilation flag that will disable @:build macro on hxd.Res as well as provide generic hxd.Res.loader property that was generated by build macro.
It does not affect regular operation in any way and is purely an opt-in feature.

Rationale: This build macro can notably impact completion times for completion server, and paired with nightly Haxe HXB system being extremely slow for small projects (as 3 days of suffering on recent Ludum Dare shown) - being able to easily disable Res completion is direly needed. It's also useful for people who don't use the provided completion, yet still end up with extra completion lag due to it being enabled.

A much more subjective rationale:

I have a lot of colorful epithets for entire HXB system introduced in HaxeFoundation/haxe#11504 as it caused completion server to be practically useless for majority of Ludum Dare, and actively caused me problems, so unless in-memory completion cache system is back - crutches like this are mandatory to make Haxe remotely viable for small, time-constrained projects. This was my worst Ludum Dare to date for the single reason of writing code being the most painful experience I've ever had with Haxe and I was openly talking about it in a far more colorful language in Haxe discord #gamedev channel around end of LD. Pre-HXB Haxe completion times are 2 to 10 times faster than HXB depending on how long the server was alive as well as server cold-start times are abysmally slower. HXB seem to not work well with Heaps build macro-driven systems as vshaxe server timings report pretty much entire time being spent inside hxb classes that are touched by macro even if the completion location has nothing to do with macro in question.

[ncannasse]

@Yanrishatum I prefer that we fix the origin of the problem than introduce temporary workarounds in the code.
Usually even with HXB once the macro code is processed (hxd.Res first compilation) the macro should not be triggered again unless the /res directory has changed, pinging @kLabz for additional HXB insight

[kLabz]

Display requests timings over time have several parameters (likely incomplete, and in no particular order):

1. Raw timing of a request
2. Depletion of cache over time
3. Cache getting corrupted, breaking both display requests and compilation through server (need a restart)
4. VsHaxe requests queue (unneeded requests should ™️ not be kept in there already, but we can't make a requests until previous one is done, which also includes compiling through server and running diagnostics)
5. Compiler's GC runs, adding an overhead to some requests (should happen after returning, but because of 4. it still has an impact) that I've seen go over 5 seconds

Hxb does make 1. generally longer for the happy path, though there are still optimizations to be made (latest being HaxeFoundation/haxe#11511) to make the overhead smaller. But it also allows us to have display requests that have no impact on cache, meaning:

• 3. should not happen anymore, unless macros mess up big time
• When something goes wrong (including things like having errors in our code) during a display request, cache is still fine while before it was often triggering 2. or was unusable until next successful compilation through server
• Display requests can now technically be aborted anytime, meaning we can tackle 4. (though we'd still need ocaml 5 for nice parallel requests) and hopefully make 5. unnoticeable
• There are things that we could try with hxb that would reduce 2. (and would have a positive impact on 1. too)

Restoring in-memory cache, at least partially, is considered too (HaxeFoundation/haxe#11519) but will need to be done carefully and likely won't work nicely for "user code" that tends to be invalidated often.

Also, having 1. so high on small scale heaps projects seems to be linked to a lot of modules (11k+ in my case, meaning display requests are barely under 200ms) being typed during completion requests, which seem to be way more than needed. I'm investigating what's going on.