[hal] Fix potential race in CANAPI

[rzblue]

Currently, the call to HAL_CAN_SendMessage is not synchronized with updates to periodicSends (which represents the internal state of the netcomm sender thread).

Now, the mutex is locked before HAL_CAN_SendMessage is called to ensure the update is atomic.
periodicSends and receives also now have their own mutexes to reduce unnecessary contention between send and receive functions.

Ex:
Thread A calls HAL_StopCANPacketRepeating with apiId 0
Thread B calls HAL_WriteCANPacketRepeating with apiId 0 and repeatMs 10
Inside HAL_StopCANPacketRepeating, Thread A calls HAL_CAN_SendMessage, which updates netcomm's state to not repeat the packet
Thread A is paused
Inside HAL_WriteCANPacketRepeating, Thread B calls HAL_CAN_SendMessage, which updates netcomm's state to repeat the packet
Thread B locks the mutex
Thread B updates the map to indicate the new state (packet is repeating)
Thread B exits HAL_WriteCANPacketRepeating and unlocks the mutex
Thread A resumes
Thread A locks the mutex
Thread A updates the map with what it thinks the new state is (packet is not repeating)
Thread A exits HAL_StopCANPacketRepeating and unlocks the mutex
Thread A calls HAL_CleanCAN, which doesn't stop the repeating packet because the state has diverged.

[rzblue]

Question for @ThadHouse: will netcomm still update its internal state if it returns an error?

[ThadHouse]

I am unsure. But I do seem to remember a mention from NI that those functions basically can't fail when any of the periodic flags are set.

[rzblue]

I've removed the status check on tx functions, making the assumption that even if the function returns a bad status, the periodic state will still have been updated.

[PeterJohnson]

Needs conflicts resolved.