Run some filters in diagnostics

[Simn]

Opening PR so I don't forget, because I kind of did.

Something is still failing which has to be investigated.

[kLabz]

Problem is, this (and 7321f18) also run on DMUsage and DMImplementation requests which seem different enough (dms_inline being false for example) to break (during filters atm and possibly at other points?)

As said on slack, there are failures here for find reference requests (for example on 9044 and 9446 display tests), hitting a die + assertion failure while running RenameVars filter (determine_overlaps runs into unexpected state in haxe.macro.Printer.printField for example because of an inline local function).

Checking other failures (damn CI noise with network requests failing again...)

---

Macro failures seem to be mostly the same, with lots of Failed to locate variable declaration failures for @usage display requests, similarly to above (while handling haxe.format.JsonParser mostly?)

Seems to be hanging locally too if I don't avoid the die on these errors.

[RblSb]

Something else to do here? Test fail seems patched
https://github.com/HaxeFoundation/haxe/blob/development/tests/display/src/cases/Issue11203.hx

[kLabz]

Let's see what CI has to say about it

[kLabz]

Nope, still broken here.

[Simn]

#11229 wasn't a good fix for #11203. I'm not even sure why it does anything at all because that @:compilerGenerated metadata doesn't make it to Diagnostics.check_other_things:

function() {
  	var future = _Main.Future_Impl_._new();
  	haxe.Log.trace("much side effect!", {fileName : "source/Main.hx", lineNumber : 13, className : "_Main.Future_Impl_", methodName : "eager"});
  }

There's a chance that this fix was only incidental, though I don't know how that could happen yet.

It also doesn't deal with the situation where future is reported as an unused variable. I'll disable this test and, if nothing else fails, merge this PR. We can then look into fixing the original issue properly.

[Simn]

The story here is that #11229 generated this @:compilerGenerated metadata, but also changed reduce_expr to remove it again. Thus when running the filters, the metadata is gone and the original problem triggers.

This took me forever to properly reproduce because I didn't realize that our display tests run without a specified target. This means we have com.platform = Cross, which causes the analyzer to not run. The analyzer cleans up the useless block-level cast expression, so the issue doesn't reproduce on "real" diagnostics runs and is exclusive to the test.