book(dev): document the process for adding new workspace crates

[ROMemories]

Not sure the Coding Conventions is the best place to document this, maybe we should have a book section for documenting processes.

[elenaf9]

Subjective opinion: not sure if we really need this section, given that we don't add new crates that often
The first couple of points aren't RIOT-rs specific. Only really the points about rexporting the crate from riot-rs and adding it (and potential features flag) to the CI are. Maybe it makes sense to have them, but then I'm in favor of shortening it down.

But not a strong opinion :)

[ROMemories]

Subjective opinion: not sure if we really need this section, given that we don't add new crates that often

I agree it's not a weekly event, but it does happen quite regularly: riot-rs-random was added two weeks ago, and I'm in the process of adding two more (for the sensor abstraction and the built-in sensors).

The first couple of points aren't RIOT-rs specific.

I also agree that not all of it is RIOT-rs-specific, but it helps clarify what tools and configuration we embrace, especially as these are always changing—e.g., inheritance of workspace lints was only added a few months ago and I was personally pleasantly surprised when I saw that using cargo init to add a new workspace crate automatically makes that new crate inherits the workspace lints. It additionally allows us to make explicit some policies that cannot be inferred from the current state of the codebase.
That process is also likely to be relevant to new contributors, as the first step of adding a new piece of functionality may well be to create a new workspace crate.