Allow explicit per-project specification for code-hinting and documentation

Is your feature request related to a problem?

Currently, all the built-in stuff is documented via the GMLSpec file, which allows all the autocompletion hinting and such.

For custom stuff, Feather automatically tries to infer some relevant types and set of variables, and additionally there's JSDoc to specify parameters.

However, in some scenarios JSDoc doesn't yet work (e.g. on macros, apparently) and in some cases it'd take some real Feather-side gymnastics to make it work. E.g. if someone wants to extend a pseudo-namespace (a function that does nothing but define static functions) using the following method:

/// @func extra_function()
/// @desc Does some extra stuff.
MyNamespace.extra_function = function() {
     // do stuff
}

Describe the solution you'd like

Allow some kind of per-project settings similar to GMLSpec file, which would provide Feather with extra information how to autocomplete/document functions/variables/etc. without necessarily having to parse JSDocs to obtain that information.

Ideally, whatever kind of auto-completion and documentation tooltips Feather can infer from JSDocs and code would be overrideable by the per-project specification. E.g. one could specify that a certain struct or object variable is supposed to have a specific type, or provide different "extra_function" documentations depending on which constructor is the current context.

In such a model, the autocomplete and documentation would be determined based on (starting from the highest precedence):

per-project explicit specification
JSDocs
Feather type inference etc.
GMLSpec

Describe alternatives you've considered

Making JSDoc-based hinting even more powerful and handling even more outlandish scenarios. But this is likely complicated to code and with more cases to explore, it may adversely affect performance.

Another option would be having the specification defined in standalone JSDocs; e.g. if a @func or @var or @macro or whatever isn't followed by any GML symbol, it's treated as a part of the specification, and any subsequent JSDoc annotations apply to the function/variable/macro/whatever until meeting another "top-level" JSDoc like @func/@var/@macro.

Additional context

No response

DEEP CASES

/// @description My Description 1st
function room_create_optimize_texture_groups() {
   // ...
};

/// @description My Description 2nd
function event_room_create() {

  // CASE 1: use alias
  var namespace = static_get(event_room_create);

  // CASE 2: use string accessor
  // CASE 3: use JSDoc from other function
  namespace[$ "optimize_texture_groups"] = room_create_optimize_texture_groups;

  // CASE 4: use real accessor
  // It's like converting to "0", but not because of the presence of DECIMAL, HEXADECIMAL and BINARY FLAGS
  namespace[$ 0] = static_get(event_room_create_managers);

  // CASE 5: use enum accessor
  // It's like converting to "123" if RoomId.EndGame = 123
  namespace[$ RoomId.EndGame] = static_get(event_room_create_end_game);
};

CASE 1

hovering over namespace shows a pop-up window with: My Description 2nd

CASE 2

CASE 3

event.room.create.optimize_texture_groups();

hovering over optimize_texture_groups shows a pop-up window with: My Description 1st

CASE 4

event.room.create[$ 0b0000].managers.init();

hovering over init shows a correct pop-up window too. hovering over managers shows a correct pop-up window too.

CASE 5

event.room.create[$ RoomId.EndGame].show_end_screen();

hovering over show_end_screen shows a correct pop-up window too.

YoYoGames / GameMaker-Bugs