Setup a proper CI

[haxscramper]

The project API is stable enough, so I need to consider setting up a proper set of tests for all the reader frontends. Right now, hcparse has several dependencies

• libclang library - ubunty impish ships with libclang 13.0, can just apt-get install libclang-dev while using conainer: in the CI configuration
• tree-sitter library - would require manual installation of the runtime, pretty simple to do
• conan package manager - not a mandatory requirement, but I need to test integration with it
• boost::wave - part of the code reader

Compilation of the project itself is relatively straightforward - first I need to build a read_boost_wave shared library (C wrapper around boost wave API) and then everything else is just a nim compilation.

Related #4, #17

[haxscramper]

https://github.com/haxscramper/hcparse/commit/23046cb60e1f9bb380147d0a8ec8e4fff8d1e1bb makes CI pass on arch Linux - I will need to test on more than one Linux distro, mainly because there are some differences in handling of the global include directories, how package management functions and so on.

I don't know why, but GitHub pages are not properly deployed after build, even though documentation builds correctly.

Overall, I think this CI thing was a bit of a stretch when it comes to the tooling stability - it is mostly related to hmisc and unit testing framework implementation. Right now it is too fragile, somewhat hackishly implemented and does not provide good enough integration with CI and related entries. In addition to that - errors are reported very inconsistently, and it is hard to understand what is wrong with the code. Other testing alternatives are not much better (I don't think I need the level of testing https://github.com/disruptek/balls provides, testament is an absolute hack, std/unittest is anemic and does not support half of what I've implemented for hmisc unittesting). This must be fixed before I can finally say that hcparse CI is a reliable indication of the project stability (because right now it is only an indication that you can build it and run limited number of unit tests)

[haxscramper]

Most of the time in CI run (~8 and ~14 minutes for Arch and Ubuntu, respectively) is spent on building boost wave dependencies. I could've made it faster by using arch-provided version (on arch CI), but that would partially defeat the purpose of using conan in the first place (and locally I test using conan packages as well). Different boost::wave version have a varying number of token enum kinds, and it might be really unsafe to try and disregard that.

Can conan build step be cached somehow?