Using C++ based markdown parser instead of marked.js

This merge replace the marked.js file, currently used to parse markdown, by a C++ equivalent composed of 8 files (headers included). This equivalent is not custom made from scratch but is rather a translation of marked.js into a new language.

Goals :

1. Making the parsing process more clear and inline with the rest of the project.

The current solution is, as the name imply, a single Javascript file 'lost' somewhere in the project directory. The general "rule" of the project is to make "heavy" logic in C++ files wich are stored under "src/logic/". As said earlier the new implementation is composed of 4 pairs of .h + .cpp files, stored in the /logic directory.

Why 4 pairs ? To Split the code into multiple, more readable, peaces.

2. Cleaning up "dead" code

marked.js is a wonderful and very powerful project, but in this case it might be to powerful. While the current setup work like a charm, the parser can be customize heavily depending on the given arguments. This means that the code has a lot of options that will never be used, sitting there, taking space and making it harder to read and understand the code. The C++ implementation is a "translation" of marked.js as if the options currently being used were the only one to exist, removing any "useless" code. As a side note, if needed in the futur, those options can still be easily added and in a more clear way.

3. Removing the need of "bridge" between qml and the WebEngineView

There's currently 4 qwebChannel being used :

1. pass raw text to be parsed
2. pass CSS variable
3. pass home path
4. pass note path

The C++ implementation, being more tightly integrated with the rest of the code, we can now avoid relying on any of those.

We can instead split the html into 2 part :

1. Style: using the loadStyle and changeStyle function with the result being encapsulated inside a <style> tag
2. Content: using the Parser.parse function which will output html

Those part will then be assembled and pass to the WebEngineView using the built-in method loadHtml.

(which might also solve the issue related to !13 (merged), see this comment, more test need to be done before I can assure it)

4. Help implementing other features

• By integrating the parser more tighly with the treeModel, this could reduce the amount of work needed to make #4 (closed) . We need to now quicly which note exist and are accessible if we want to link them ;)
• Having more information and acces to the rest of the project/system directly could reduce the amount of work needed to make #5 (closed) . Creating images on the fly is easier in C++
• Having code highliting for block of code
• Other might come in the futur

To conclude. While this is a big change and quite a lot of code being added and needed to be maintained, I think it's worth the effort. The maintainance of this code will be low, QRegularExpression is pretty stable. And the rest of the goals will make life way easier in the future, especially point 1 and 2 for maintenance/tweaks and point 4 for reasons that I already explain.

Note: the current implementation doesn't include the change that have been added to marked.js from !19 (merged) since this merge has not been reviewed yet, but those change will be really easy to implement.