hal: Fix implementation types and small adjustments

[BsAtHome]

In this PR:

• Fix some types (still all compatible). The function signatures of the new functions were correct, but the implementations lagged.
• A long standing bug in hal_link would not properly copy the 64-bit value from the dummy to the signal, but would only set the lower 32-bit value. This has now been corrected.
• Final preparations are put in place for introducing the HAL query API.
• Update the comment in hal_init_data regarding the mutex.

This PR introduces hal_strerror() for textual representation of the negative error value from many of the HAL functions. The return value of some HAL functions will be adapted to become more fine-grained later. Currently, they mostly return -EINVAL, which often does not describe the actual error encountered. Changing the return value should not pose any problem because the code that actually checks return values looks for equality with zero or less than zero. Returning a more differentiating (negative) value does not functionally alter that code but allows better messages to be generated moving forward.

[grandixximo]

If merge this first my #4251 will fail to build, can you provide an explicit marker like

#define HAL_HAS_QUERY_API 1

And I re-gate #4251 on that?

[BsAtHome]

If merge this first my #4251 will fail to build, can you provide an explicit marker like

Why and where does that fail?

[BsAtHome]

BTW, the next PR will provide the HAL query API. That should make most changes to these parts complete.

[grandixximo]

If merge this first my #4251 will fail to build, can you provide an explicit marker like

Why and where does that fail?

I will double check the claim in a few hours once I'm on a linux machine

arm sid is broken, are we closing an eye on that?