kobj: add DEFINE_CLASSN() for arbitrary # parent, add public/private

[ehem_freebsd_m5p.com]

Summary

There were two issues with the existing DEFINE_CLASS_#() macros. First,
the parent count was capped at 3 since every count needed a distinct
macro. Second, many uses wanted the class variable to be overtly
static (private).

By using VA_ARGS and VA_OPT there is no longer a need for a
distinct macro for every parent count. This also allows for there to be
a single static version of the macro. Also start using a designated
initializer for the main structure.

[ehem_freebsd_m5p.com]

Natually that last minute change breaks things.

Clang accepts VA_OPT() with the options used for building FreeBSD. I'm rather unsure as to the stance on whether it is acceptable to use due to being a fairly recent feature.

I've noticed many uses of static DEFINE_CLASS_0(...);. Issue is this doesn't work with anything besides zero parents and I would expect non-zero parents to be fairly common. As such I'm suggsting an alternative macro set which handles the static internally.

I'm unsure of appropriate reviewers. This is related to D48408, though a distinct issue with the kernel object system.

[ehem_freebsd_m5p.com]

I'm unsure of who I should ask to review this, seems close enough to the core you two may be good candidates.

[ehem_freebsd_m5p.com]

Ugh, identify the simple goof made on the original version. Going back with that corrected.

[ehem_freebsd_m5p.com]

Looking at this some more, the real value is creating PUBLIC_ and PRIVATE_ versions of the DEFINE_CLASS macros. Handling arbitrary numbers of parents mostly serves to simplify things to only needing two macros. It is notable with the current macros it is impossible to create a private/static class with at least one parent.

It might be worthwhile for PUBLIC_DEFINE_CLASSN to create extern kobj_class_t name ## _baseclasses_singleparent; since it is very common to have a single parent. Having two or more is quite uncommon.

Likely DEFINE_CLASSN should be dropped. I was thinking compatibility, but that seems dubious value. Likely drop the N suffix as the public/private prefixes are sufficient to distinguish these from the existing macros. Do kind of need reviewer attention though...