Add a bit of Javadocs, and introduce helper function for reversing directions because the ^2 trick used elsewhere in the codebase is not immediately obvious exactly what it does.
This was a regression from #7435 which introduced threads and caused JNI
to misbehave and fail to load our expected classes. Provide a workaround
based on the description in https://stackoverflow.com/a/16302771 which
stores a main thread's class loader and uses that in neighbouring
threads.
Add 'default' cases to a few enums that were not otherwise handling all possible enum values. This wasn't a problem before because the variables we were switching on were not actually enum types, but now that they are, Clang is warning us about the non-covered cases.
Previously untitled 'PEEP_ACTION_SPRITE_TYPE7' is actually a single-frame animation for sitting on benches, from looking at the sprite. Makes sense with the way the value is used in the code too.
Use the PEEP_ACTION_SPRITE_TYPE enum for rct_peep::action_sprite_type and ::next_action_sprite_type, as well as other code that deals with action sprite types.
Use the PEEP_ACTION_EVENTS enum for the rct_peep::action field explicitly, so that we get type safety on it from the compiler and debugger. In the process, force PEEP_ACTION_EVENTS to be of size uint8_t, and use named constants for NONE actions instead of magic numbers in a few places.
Explicitly declare the PEEP_STATE enum as being uint8_t width, then use it instead of uint8_t in the rct_peep struct. This has a few benefits:
* It makes it clearer which values we expect to be assigned to that variable. If you hadn't already seen PEEP_STATE existed, it wouldn't be obvious.
* It lets the compiler catch assignment of non-PEEP_STATE values for us
* It lets the debugger show us symbolic constants when looking at a peep, instead of raw values.
The only downside is that we no longer see directly in the rct_peep struct that the field is 1 byte wide, but I think that the benefits outweigh the costs in this case...
