[developer] Define and write the ECS guides

[heysokam]

Converts the ECS article into a section, reorganizes its structure and extends it with new content.

TODO:

Note: Break into separate tasks before working on this issue.

• Convert the single-page article into a section
  • Turn the file into a Docusaurus category folder
  • Transform the existing single-page article into a multi-page section
• Improve the structure of the existing contents
• Add new content related to DDD
• Add new content about how the engine uses the ECS pattern
• Add @anselm's suggestions to the article
• ECS system flow
• Components
  • ECS Component list
  • How to build custom ECS components
• Systems
  • When to use Reactors
    • useComponent
    • useQuery
    • Mo
  • When to use execute

Todo: Anselm's suggestions

Temporarily moved out of the Getting Started guide. Should be moved into the guide.

Ethereal Engine uses the React pattern of allowing state observers to 'react' to state changes.  
This is done for a couple of different reasons.  
- **Philosophically**: It separates the 'what' from the 'how'
- **Technically**: It helps decouple game components from each other, allowing developers to scale work horizontally, reducing dependencies.

:::info
The React website has several good discussions on reactivity as a whole:  
https://react.dev/learn/reacting-to-input-with-state
:::

Note: The target audience is intermediate technical users.

[heysokam]

Suggestion by @anselm (paraphrased)

There could be more detailed docs on why ecs or how the ecs pattern works a bit more philosophically.
In my mind that can be a brief discussion.

I feel like the core pattern of the engine is to encourage developers to use a declarative or data driven pattern for expressing the objects and relationships. The goal is to separate the WHAT from the HOW. And the reason ECS maps well to that is that it encourages granularity.

The difference is pretty clear if you compare a traditional Threejs application (such as building a simple scene) with an ECS approach.
In the former you are mixing two separate things together; you are specifying state AND you are talking to an api.

For example here you focus on both WHAT and HOW:

const scene = new scene()
const camera = new camera()
scene.add(camera)

Whereas in a data driven pattern you're tending to focus just on WHAT:

const elements = [
  { type: scene }
  { type: camera, parent: scene }
]
loadstuff(elements)

Philosophically the latter approach is cleaner.