"How GWT works" section, provide more background/decisions made by the project

[niloc132]

One of the biggest issues in the handoff from Google to the open source community is the lack of (or destruction/deletion/hiding of) design docs and how decisions were made along the way - the gwt-code-reviews.appspot.com (note that as of writing, this DNS record still exists and has an http server behind it, but just isn't public) instance wasn't able to be updated and Google was unable/unwilling to export the database. Deleted documents include early jsinterop work, originally located at https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit. Even from the frozen gwt-reviews site, there remain code reviews of changes that were merged into GWT well after it was open sourced that are unavailable to maintainers (e.g. https://gwt-review.googlesource.com/c/gwt/+/13418 / gwtproject/gwt@a0d61dc). Throughout the steering committee process, open source maintainers requested public design docs for work or changes, but this rarely resulted in actual intermediate deliverables for completed projects, and effectively never for work that didn't pan out (e.g. experiments that turned out not to be worth it, so future maintainers shouldn't bother trying again).

For my own part, I've tried to document my thought process and intermediate steps in github issues, and to push incomplete branches to my own fork. I don't think this is sufficient though, and wouldn't make it easy for someone else to resume everything that I've been working on.

Most of this probably belongs in the project's github issues or in source control rather than the website, but there is still a lot of general information that isn't documented.

Proposed general topics to add to gwt-site:

• Different ASTs used (JDT, GWT, JS)
• Design tradeoffs, history, alternative tools that make different tradeoffs
• Rebind mechanisms, how these are used, why they are discouraged (if not deprecated)
• Steps when compiling (modules, parsing sources, normalization and optimization), eventually breaking down those into more specifics
• "magic" methods, and other important not-quite-java
• internal annotations
• What can you assume that the compiler will do for you
• Why did the compiler not optimize something it could have
• How to see what the compiler did, or how to debug when something goes wrong