scripts: west_commands: Add 'new' command

[wkhadgar]

Add a 'new' west command as helper for Zephyr projects, drivers and modules.

The project creation is the default state, generating a minimal configuration for a Zephyr app. The module creation consists of a simple template to be completed by the user. Driver creation follows the example_application format, producing or appending the created driver skeleton into the drivers and dts/bindings directories.

This west command aims to ease developers load when starting new projects, or porting existing code into drivers/modules that operate with west and Zephyr.

[wkhadgar]

Just noticed @kartben also got the same idea with #95798, maybe we could merge PRs?
Not sure how to proceed here

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[henrikbrixandersen]

I think adding something like this requires more discussion. For instance, the code is embedded in a Python script - and it doesn't even follow the established naming of structs and macros.

To be honest, I don't see much value in generating boilerplate code this simple.

[wkhadgar]

I think adding something like this requires more discussion.

Definitely! This is something I've been talking about with some other developers and they all agreed it would be nice to have a "quick starter" for smaller building blocks on Zephyr like drivers and modules, that's the main force that made me implement this

For instance, the code is embedded in a Python script - and it doesn't even follow the established naming of structs and macros.

Well, I'm not really going for a stone written like code to be generated, instead it would be necessary to do your modifications to the generated templates, it is more of a sample than an actual thing that should be used as is, not sure if I'm being clear, but we could discuss this further! Maybe an RFC?

To be honest, I don't see much value in generating boilerplate code this simple.

I guess we could also discuss that! I went deliberately to the as simple as possible way, since it should be more of a building block than a full feature maker, I'm afraid that over doing templates would sorta limit the user implementations or embed some personal code style into the templates and so on.

[nordicjm]

I agree with Brix, and notwithstanding that the filenames and symbol names this seems to use seem completely arbitrary and not matching what is used in-tree

[wkhadgar]

the filenames and symbol names this seems to use seem completely arbitrary and not matching what is used in-tree

I based the naming and structuring on the current example_application, though it may not be up to date?

I would happily change the naming to the best possible! Also, the only out-of-pocket thing I had to make was the _drv postfix of the driver implementation, since you only provide the driver class name, and at least one driver implementation should be given to the user to work with.

Other option would be templating not a whole driver class, but only a driver implementation instead, giving to the tool in which class you're planting your implemention... or something like that?

I guess maybe this could be another option, so the user may choose to implement only a class and then implement a driver for that class with its own name? Looks better to me since it modularizes better... Not sure if you agree @henrikbrixandersen @nordicjm