Update: Major improvements in locking logic.

Update: Major improvements in locking logic.

Major Improvements:
- Add custom thread status checking functions (also replacing `controller_thread_is_enabled()` with `controller_thread_enable_is()`).
- The thread enable property is now `enable` rather than `enabled`.
- Add new `controller_thread_enable_none_e` to allow for handling default behavior.
- Add new `enable` read/write lock to better handle the reading and writing of the enable property.
- Change the signalling logic to directly call `f_thread_condition_signal_all()` and to not read lock the conditions on signal send.
- Change the lock status checks to more explicitly check for `F_okay` so that unknown conditions without error bit set are ignored.

Being explicit on handling the `F_okay` helps ensures that the lock is guaranteed to be set.

I think I need to additional review and re-structuring of the thread logic beyond this commit.
There will likely be additional commits in the future to further improve the locking logic.

I believe that there are some cases where unlock might be called on a not-locked lock.
The additional work will likely include addressing this.
I suspect this is happening in cases where the same function is called in two different contexts.
One context is directly from a thread and another is in the middle of processing something.
The lock might not be set in the case of the directly calling from the thread.