We destroy the log console before the final flush, take that into
account => disable handle message for the ConsoleLogSinkDispatcher if
the corresponding LogConsole was destroyed.

This is a quick and dirty solution, but I don't know any other way for
now!

Because we create a shared_ptr, and because the MainWindow will delete
the widget on exit, we have a double free error...

LOG: Add a worker thread for logs, it will launch the `flush` operation in a thread-safe way when logs are available

MISC: Get ride of VivyCli and everything is placed in VivyApplication (because of the way to get the log sink)

/!\ REGRESSION: We no longer have the line of the last lua error!

- The message no longer outlives the logger
- Update the objects that use the LOG API
- Print more things with the stderr dispatcher
- The UI, src/Lib, src/Lib/Ass, src/Lib/Document use the new LOG API

LOG: Add some logs, pb on flush on exit because the messages outlive the logger (string_view problem)

TODO: Don't depend on the order of the includes

LOG: Add a way to get the sink from the VivyApplication and add more possibilities for logging things

MISC: Separate implementation of the different classes of Log.hh into multiple namespace Vivy{} in the Log.cc file

LOG: Send the messages to the queue in a thread safe way, clear the loggers from sink cache on destruction

This is a slightly more complicated logger than what is done for lektor.
The process to create a logger is the following:

{ // In scope
std::shared_ptr<LogSink> mySink   = VIVY_NEW_LOG_SINK();
std::shared_ptr<Logger> appLog    = VIVY_GET_LOGGER(mySink, "APPLICATION");
std::shared_ptr<Logger> scriptLog = VIVY_GET_LOGGER(mySink, "SCRIPT");
// ...
VIVY_LOG_WARN(appLog) << "This is" << ' ' << "very usefull!";
// ...
} // Will clear all loggers

MISC: Can now use qDebug() with std::string and std::string_view, VIVY_ASSERT_STRING is now a qFatal

Implement the VivyDocument specification

See merge request !18