hal: Introduce post_export in halcompile so parameters can be preset

[BsAtHome]

Parameters can no longer be written before being created. Some components use the EXTRA_SETUP() code to set parameters, but that code runs before they are created and cause a crash now.

This PR introduces a POST_EXPORT() function with halcompile option post_export yes that runs at the very end of the export() function. It is guaranteed that all pins and parameters are created and the thread functions registered at the point where POST_EXPORT() is called. The signature of the function is the same as with EXTRA_SETUP().

The PR also resubmits the component that exposed the problem, multiswitch.comp. It should now function properly and no longer crash.

[grandixximo]

The POST_EXPORT hook itself works and the codegen looks right, but multiswitch crashes with this change. loadrt multiswitch cfg=4 creates no bit-XX pins at all, and starting a thread segfaults rtapi_app: hal_set_bool (ref=0x0) at multiswitch.comp:65, called from thread_task. Core backtrace available if useful.

This might be because personality is a modparam defaulting to 0, and EXTRA_SETUP's personality assignment was reloaded by the generated code before pin creation (halcompile.g "may have changed the personality" reload). Moving that line to POST_EXPORT means the pins are sized with personality 0, while FUNCTION still loops over the inst->_personality written later. With cfg=4 personality=4 the pins appear, so the mechanism checks out, but requiring personality= would change the documented cfg= interface.

What works here (tested): keep EXTRA_SETUP for the personality line only, and use POST_EXPORT only for top_position_set(cfg[extra_arg] - 1). With that split, cfg=4 alone creates bit-00..03 and top-position=3 and the thread runs clean.

One doc suggestion: comp.adoc might warn that POST_EXPORT must not change personality, since it is too late to size the pins but still changes the loop bound seen by FUNCTION.

[BsAtHome]

You are right. So...many...hacks...in this code.

Split the EXTRA_SETUP, retaining the personality change and added POST_EXPORT to set the parameter. Also added a comment to the docs.

[grandixximo]

Confirmed the respin: loadrt multiswitch cfg=4 now creates bit-00..03, top-position=3, and the thread runs clean. Looks good to merge from my side.

On the hacks: agreed, and for the record the hack here predates both of us. multiswitch overloads cfg= to carry pin counts and rewrites personality in EXTRA_SETUP, which is also the only in-tree user of the "extra_setup may change personality" reload in halcompile. Your split contains it about as well as it can be contained without touching the cfg= interface.

If it ever starts to bother us enough, there maybe a cleaner road: give halcompile a get_personality(long idx) hook next to get_count (option personality_function yes), so a count_function comp can report per-instance personality before export() runs. multiswitch would then drop EXTRA_SETUP entirely, pins would be sized correctly from the start, and the reload quirk could eventually go away. Probably not something we want to do now, if ever, thoughts?

[BsAtHome]

You are right, a cleanup may be in order at some point.

There are several other component files that set the personality in EXTRA_SETUP. At least they do not touch anything else that is problematic.

Lets get through the getter/setter first and then we can already retire the old types in halcompile. After that we can discuss scrubbing with stronger cleaning aids and acids ;-)