## About The Pull Request
One of my upcoming PRs affects a significant chunk of the codebase so
I'm cleaning up messes that I've found along the way.
This PR adds wrappers for adjusting sanity/checking if a mob already has
a certain moodlet, fixes an oversight where attempting to set sanity
over passed maximum would abort the change outright (instead of actually
capping it out), moved jolly and depression processing into quirks
themselves (instead of having dedicated traits for them used solely by
said quirks and nothing else that are constantly checked for by mood
datums), and rewrote how blessings return their results to move omen's
deletion on blessing effect from constantly checking mood for a blessing
moodlet to a comsig.
## Why It's Good For The Game
Less jank handling of certain mechanics, we ***really*** shouldn't be
checking for blessings every time mood of all things is updated.
## Changelog
🆑
fix: Adjusting sanity over the allowed maximum will no longer completely
halt the change, and instead actually cap it at the maximum value.
code: Cleaned up mood and mood-adjacent code.
/🆑
Loosely adapted from /vg/. This is an entity component system for adding behaviours to datums when inheritance doesn't quite cut it. By using signals and events instead of direct inheritance, you can inject behaviours without hacky overloads. It requires a different method of thinking, but is not hard to use correctly. If a behaviour can have application across more than one thing. Make it generic, make it a component. Atom/mob/obj event? Give it a signal, and forward its arguments with a SendSignal() call. Now every component that want's to can also know about this happening.
cf131db497