Add support for building only on a single system

[hesiod]

This PR adds support for building only on a single system. The proposed syntax based on build_system is only a suggestion, I'm open to better ideas.

I took the liberty of breaking the comment parser into a few modular sub-parsers in the process, as it was a little convoluted previously. In any case, the parser is still using the relatively old nom version 4.2.3. Newer nom versions use functions instead of macros (see the migration guide). At some point the parser should be rewritten using this new style, but I didn't do it in this PR to keep it simple.

Note: I can't test the PR using a live builder as I'm not running one. I'm opening the PR anyway as the README says this is OK due to the lack of test environments for ofborg.

Closes #232.

[SuperSandro2000]

The need for this roots from a different problem: people using ofborg for debugging which is not great. For every push the eval task runs which is rather expensive.

[hesiod]

I'm a little conflicted about this. Certainly ofborg should not be the primary development tool while working on a PR. On the other hand, if you're trying to debug a build failure on a foreign architecture ofborg can be the only way to properly test a PR.
According to the docs and the code, it should be possible to skip evaluation by assigning the work-in-progress label to a PR. However, for some reason this does not seem to stop ofborg from running the eval task (see ofborg/src/tasks/evaluate.rs), at least when I tested it. Perhaps it would make sense to skip the eval task for all draft PRs.

Personally, I don't have access to any macOS systems and other than ofborg I don't know about another way to test whether a package builds on Darwin.