Potentially replace locks to improve performance

[Net5F]

notify(), subscribe(), and unsubscribe() currently all acquire a scoped_lock before accessing/modifying queueVectorMap. This is to maintain thread safety in case someone tries to sub/unsub and notify at the same time. (Note that getQueueVectorForType() also potentially modifies the map.)

If we remove the locks, notify() will potentially get a performance boost. In my not-great test at the bottom of TestQueuedEvents.cpp, it goes from 2x the overhead of the raw ReaderWriteQueue to just 1.4x.

I can see a scenario where we sacrifice the ability to notify & sub/unsub at the same time in favor of a faster notify (people can synchronize it themselves if they care to). This is justifiable since most use cases probably involve constructing all of your queues once at the start of your application, and then only ever notifying.

If we do this, we would have to find an efficient way to error if someone does try to call notify & sub/unsub at the same time (maybe only enable it in debug? that might be fine). We would also have to solve the case of destruction at the end of the application's life cycle (producer threads may try to notify while the consumer is already destructing).

[Net5F]

Performance is closer to a raw queue after switching the queued type to a non-shared_ptr. This shows that the current minimal testing isn't very useful. Would need better testing to make a decision here.