[FEATURE] Improve `Material` and `TextureContainer` API ergonomics (avoid raw string keys, allow per-attribute setters)

[Miou-zora]

Problem Statement

Two related API ergonomics issues affect the Material component and TextureContainer resource, both flagged in ES-Factoria src/system/CreatePlanet.cpp:

1. Raw string texture keys — Texture names must be passed as bare string literals in multiple places, with no type-safe handle or constant to prevent typos:

textureManager.Add("CustomTexture", ...); // TODO: be able to put variable rather than raw string

2. Full struct construction required — Setting a single Material attribute after component creation is cumbersome; there is no fluent setter API:

// TODO: be able to set attributes like this rather than having to push a complete struct

Proposed Solution

• Introduce a typed texture handle or at least a named-constant mechanism so texture names are defined once and referenced safely.
• Improve the Material component API to allow per-attribute setters (builder pattern or direct field assignment after AddComponent) without constructing a full struct upfront.

Alternative Solutions

• Use a string-interning or hash mechanism to at least catch typos at runtime — partial improvement with no API change.
• Accept the current design and document it — no effort, but leaves all consumers writing repetitive struct initialization boilerplate.

Use Cases

• Use case 1: A developer sets only the diffuse texture on a material without constructing and moving a full Material struct.
• Use case 2: A texture is referenced as a typed handle (or constant), making a typo a compile-time or early runtime error rather than a silent miss.

Impact

• Improved developer ergonomics with no performance cost.
• Potentially minor API additions to Material and TextureContainer.
• No breaking changes if additive; breaking if existing struct-based API is replaced.

Additional Context

Spotted via a // TODO audit of the ES-Factoria demo project.

Related Issues

• N/A