Added go-to-definition feature to weidu .d files

[podcherklife]

This PR adds limited go-to-defintion feature for weidu .d files.

Definitions are collected only from open files.
Go-to-definition works only for GOTO and EXTERN weidu commands.

Notes regarding implementation:

Holding clrl causes file to be re-parsed on every cursor move. I did not notice any visible impact on performance even for large files, but you mileage may vary.

I got a bit confused about how to implement a language-specific symbol lookup, and went the most direct way. Suggestions on how to properly improve that are welcome.

Files in src/dparser/* were generated from this grammar: https://gitlab.com/lapdu/lapdu-parser/-/tree/master/src/main/antlr4/imports
They can be generated by build script instead, but that would require java dependency during build which might be undesirable.

[burner1024]

That's cool.
I've been meaning to get to ANTLR4 next, in particular as the road to autoformatting.

Language-specific features I prefer to put into corresponding weidu.ts or fallout.ts files. Or, failing that, route through Galactus

VScode-BGforge-MLS/server/src/galactus.ts

Lines 231 to 233 in 96f48ca

	// the only language with external headers dir
	if (l.id == "fallout-ssl") {
	language = new Language(

But there's been no need for language-specific lookup. I guess you can pass langId to symbolAtPosition and handle the switch there, in common.ts
Doesn't current symbolAtPosition return correct symbol, though?

They can be generated by build script instead, but that would require java dependency during build which might be undesirable.

Yes, will need the generation script. Not necessarily at build time, but need to have a way to regenerate this automatically.
See https://github.com/BGforgeNet/VScode-BGforge-MLS/blob/master/scripts/ie-update.sh for an example. I just checkout upstream repos into ./external and pull data. Kind of horrible, but better than nothing, upstreams don't change often.

Also seems ESlint is plenty angry.