Transparent background - bad for dark theme as lines are dark
White background - bad for eyes when using dark theme at night :D
Black background - can't C#
Gray - LGTM :)
On debian buster with gcc 8.3 I see the following compiler error:
```
[build] FAILED: 3rdparty/eventbus/use_case/basic/UseCase_Basic
[build] : && /bin/g++-8 -DTORRENT_NO_DEPRECATE=1 -DSPDLOG_FMT_EXTERNAL=1 -DJSONCONS_HAS_OPTIONAL=1 -DNO_BOOST_SERIALIZATION=1 -DGSL_THROW_ON_CONTRACT_VIOLATION -DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_INFO -g 3rdparty/eventbus/use_case/basic/CMakeFiles/UseCase_Basic.dir/src/main.cpp.o -o 3rdparty/eventbus/use_case/basic/UseCase_Basic 3rdparty/eventbus/lib/libEventBus.a && :
[build] /usr/bin/ld: 3rdparty/eventbus/use_case/basic/CMakeFiles/UseCase_Basic.dir/src/main.cpp.o: in function `std::__shared_mutex_pthread::lock()':
[build] /usr/include/c++/8/shared_mutex:103: undefined reference to `pthread_rwlock_wrlock'
[build] /usr/bin/ld: 3rdparty/eventbus/use_case/basic/CMakeFiles/UseCase_Basic.dir/src/main.cpp.o: in function `std::__shared_mutex_pthread::unlock()':
[build] /usr/include/c++/8/shared_mutex:123: undefined reference to `pthread_rwlock_unlock'
[build] /usr/bin/ld: 3rdparty/eventbus/lib/libEventBus.a(EventBus.cpp.o): in function `std::__shared_mutex_pthread::lock_shared()':
[build] /usr/include/c++/8/shared_mutex:139: undefined reference to `pthread_rwlock_rdlock'
[build] collect2: error: ld returned 1 exit status
```
This adds threads to the linker arguments.
In some scenarios we could end up with UB. I added simple example in test case where we add class
instance to vector and as we know it may move its elements when resizing.
Maybe we could allow to move and just unlisten previous listener but this would be very annoying as
user needs to remember what would happen in every case. It is better to let user decide and force
him to think about it.
We should be able to remove installed stuff but we want to forbid changes in installed files.
Thanks to that we do not modify files by mistake directly from e.g. Clion (when we go to
header/source)
I don't like to keep separate folders for public & private stuff. In my opinion this is "old"
approach. I like when header and module file are next to each other.
My choice. Installation will handle splitting public & private headers.
There could be not nice situation when bus dies and Listener wants to unlisten. That was easy to
achieve e.g. bad order in class fields. (Order of destruction matters)
