Usermod bus type

[jw2013]

PR regarding bus implementations as usermods, as discussed with @blazoncek

[softhack007]

maintainers call for discussion: i think we should first understand if an "adding a bus by usermod" feature still fits to our future view of the WLED architecture.

[blazoncek]

Since I'm no longer one of the WLED development team members I'll try to explain why I thought this was a good idea at the time.

Bus architecture is IMO good and flexible (though it could be better still) so adding a user extensible bus seemed nice addition to allow (advanced) users to extend output to devices of not necessarily LED type.
Once @willmmiles modified usermod architecture to be library-like this fit even more into the extensible bus architecture idea. Think of bus_wrapper.h as a usermod (with proprietary API) for NeoPixelBus driver and you'll get the idea.
Swapping LED driver is now (0.16) even easier to achieve as there are no requirements for the driver other than to support output methods. It does not need any buffers or "input" methods (AKA GetPixelColor()).
Just for fun: Perhaps consider writing driver utilizing FastLED instead of NeoPixelBus. This is now entirely possible (just needs new wrapper or usermod once API is completed).
However in its current state bus API isn't sufficient to support usermod types (including UI which may be the biggest task) so additional work will be needed.

[jw2013]

As the one who started this PR originally, despite not being involved in anything WLED related for the past year, I'm still convinced that it is useful for advanced users (as @blazoncek wrote).

There are many exotic use cases out there, that one could cover using WLED with minor additions. The project I was involved in 2024 required a way to control 'polarity change christmas lights', that typically run on 31V "AC".

I got that working by writing a phase shift pwm firmware for AT8870 motor shields, and controlling those from WLED via I2C. The same modified motor shields also work perfectly to control 12V-36V RGBW strips.

So it's certainly not for the average user, but I was glad to have that possibility back then.

[netmindz]

Any modular approach needs to support multiple types, not just one.
It also requires that we complete the work I started to truly encapsulate each driver so that we don't have common code that says things like ifVirtual(), the type array needs do actually come from each bus implementation, as per my original design, not the current awkward compromise