Allow on-demand initialization of Zephyr drivers in USER program

[lmajewski]

Is your enhancement proposal related to a problem? Please describe.
The use case is as follows:

• It is possible to extend the default, base system with add-on board(s). To be more specific - it is a PCB with PHY IC.
• This PHY board has a special GPIO controlled pin to enable power to it.

Temporary solution used
Now, there is a special SYS_INIT() hook function to always enable the power for the "expected" PHY IC module no matter if it is really present or not.

Such approach has several issues:

• It is expected that some other add-ons boards will be available in the future, so e.g. the pin control configuration may be different.
• The ETH driver is now always enabled and operational no matter if the corresponding PHY is available or not.

Describe the solution you'd like
The desired solution would be to allow the "user application" to call initialization code for the driver (i.e. pin control, PHY, ETH). In that way we could circumvent issue raised in #30692, so all the burden of multiple boards' variants support would be moved to user application without the need to massively modify Zephyr (with proper examples and documentation, so others could easily follow).

It also looks like the "support for disabled devices from DTS" may help as well (#19448).

In principle: now we do have APPLICATION initialization level in SYS_INIT() , which indicates driver initialization just before entering the main() function.
Maybe new keyword could be added (e.g. USER) to indicate that Zephyr's kernel driver (now disabled in DTS) would be initialized in user application?

Describe alternatives you've considered
It looks like Run Time Power Management [PM] could at least mimic to some degree the above functionality.
The PHY driver would be started with PM initialized as disabled. Then user application would start the transfer for the first time (and enabled power for it). After this - the PM would be disabled, so the device would be always ON.

However, this approach lacks the flexibility - so the problem with e.g. pin control for multiple add-on boards is not solved.

To sum up:

• Allowing the user space program to handle on-demand devices initialization would allow Zephyr's kernel to be not bloated, and only interested parties would use this functionality.
• Any input is more than welcome, as it would be good to at least have a clear idea of how the project is going to tacked this problem in the future (so one can align to this approach).

[carlescufi]

@lmajewski this reads a bit like a duplicate of #40385, would you agree? See also #20012

[lmajewski]

The first use case (i.e. "Add the ability to manually initialize a device:") of #40385 seems to be what I do exactly need.