v3.3.4

Experimental glz::repe::registry reworking of locking logic by @stephenberry in #1290

This makes the registry locking logic behave the same for reading and writing. This limits reading a bit more by not allowing asynchronous reads to the exact same field, but it makes asynchronous writing possible, and keeps the locking logic simpler. We can now asynchronously write to differing targets, and importantly we can call asynchronous invocations.

We are removing automatic invoke locking. With variables, there is no place for a user to put logic when it comes to locking/unlocking access. However, when it comes to functions, there is room for users to add mutexes and locks to customize lock behavior. Also, functions often have complex side effects that need to be known to the programmer. On top of this, if we don't manipulate references in an RPC, we'd like the default behavior to be able to asynchronously call these functions. For these reasons we don't automatically lock the path taken to the function call. Because we also don't want to assume that a function call would manipulate the returned state of a data, which would block reads to the data.

Full Changelog: v3.3.3...v3.3.4