Transition to a graph-based API

[HoloTheDrunk]

This is still in early development and the PR was only created to improve the visibility of progress and allow discussion regarding the design of the new API.

Note: merge conflicts with #2300 will not be an issue given that most if not all of the work towards this goal is isolated in a new folder.

Description

This PR aims to expose a generic and extensible directed acyclic graph (DAG) API over iTowns' features.
This API should also expose ways to automatically optimize the graph.
The graph should be made in such a way as to allow the progressive coverage of iTowns' features.
As a side-effect, this PR also adds support for a progressive transition to TypeScript.

Motivation and Context

iTowns currently holds together through sheer willpower, hopes and dreams.
By creating a more user-friendly API that improves feature discoverability, we aim to progressively replace old interdependent code with a more functional style of isolated units of computation, guided by the constrained environment of a DAG.
This will ideally lead to an API reminiscent in concept of Blender, VTK, DaVinci Resolve and many other modern applications and libraries that have chosen a similar data flow representation for its simplicity and ease of use among other benefits.
Since graph nodes can contain arbitrarily complex code, this would also allow for easy higher-level API development by library users targeting non-technical users by simplifying the creation of no-code but still powerful visualization tools.

Example

The examples/effects_postprocessing.html file has been altered to use the new API, showcasing what it allows.

The graph for that example ends up looking like this (generated by the included dot dumping utility methods):

Base

Optimized (only optimization available as PoC right now is screen shader merging)