Attempt to a generic workflow to add new compiler features

[mickaelistria]

Hi,
As I'm trying to make progress with JEP-445 support ( #1106 ), I've tried to identify the various pieces of work that need to be done in order to claim complete support for a new compiler feature. One objective is to facilitate tracking of progress and collaboration, so other contributors can see what's the state of the support and start building some sub-parts on top of what's already been completed.
However, there are of course some things I missed and am not yet aware of, so any feedback here from people more experienced with this topic is welcome to fix this description. I (or anyone else) will incorporate the necessary changes as soon as they've been expressed.

Here is the current version:
Unnamed class

graph BT;
    subgraph compiler
      AST(["Compiler AST"]);
      Parser(["Parser"]);
      Validation([Validation]);
      Codegen([Bytecode generation]);
      Parser --> AST;
      Validation --> AST;
      Codegen --> AST;
      Codegen --> Validation;
    end
    subgraph IDE
      DOM(JDT Core DOM);
      Warnings(Editor warnings);
      Completion(Completion);
      QuickFixes(Quick fixes);
      QuickAssist(Quick Assist);
      Hover(Hover);
      Debug(Debug);
      Index;
      DOM -. load from .-> AST;
      Index --> DOM;
      Warnings --> DOM;
      Completion --> DOM;
      QuickFixes --> DOM;
      QuickFixes --> Warnings;
      QuickFixes --> Validation;
      QuickAssist --> DOM;
      Hover --> DOM;
      Debug --> DOM;
  end
  subgraph legend
    Done("✔️ Done - link to PR")
    Review("🔬 To review - link to PR")
    Dev("⌨️ Under development")
    Todo(To Do)
    style Done fill:#00ff00
    style Review fill:#bbff00
    style Dev fill:#ffff00
  end

Loading

[mpalat]

Referring #1487 (comment)

Please see Bug Tree as an example
For example:

The JDT Core Part will have the following parts:

• Grammar changes [will have AST as the final result]
• Type Resolution [this can be combined with next 2/3 phases]
• Flow Analysis
• Code Generation
• Disassembler Changes [may be covered with codegen as well]
• DOM AST Support
• Search Support
• Java Model Support
• Selection Support
• Content Assist

General rule of thumb is to create a top level issue with the above issues as child issues and then create child issues further under each bucket if required.

Since the above bug tree was from Bugzilla, and since we moved to github, we can take a look at a tree in gthub issues-
like you can see in #890 (comment) or more closer to this as in [1106]
(#1106)

[mpalat]

start building some sub-parts on top of what's already been completed.

Grammar culminating in AST is generally the first step. Once we have the compiler AST up, the DOM, Model, etc work can (slowly - since Type info also required) start. So a good design of an appropriate AST node is essential. If possible, use an existing AST Node with additional field/flags if a new one may not be doing anything far different - an example of such a case is RecordDeclaration - although we have new node in dom ast which is well justified since the user can identify it as different, in compiler AST we just modified TypeDeclaration to include this record property to flag this as a record.