Use sandboxed spawn strategy in testing

[furtib]

Why:
The spawn_strategy=sandboxed is a much stricter testing environment. It can catch issues that can go unnoticed in some cases. (For example, setting the workaround PATH for codechecker to / works without this flag, even though it shouldn't.)
This strategy more closely mimics the restrictions of a remote worker.

What:

• Added the flag --spawn_strategy=sandboxed to CI tests. (Had to skip Buildifier since the sandboxed strategy is too restrictive for it.)
• Added a tag to Buildifier. (So that I can skip it.)
• Removed local = True from unit_test macro. (This flag prevents these kinds of tests from running with a sandboxed strategy.)

Notes:
This strategy may restrict what kind of tests we can use.

Addresses:
None

[nettle]

This is actually interesting idea!
However, I think we should be careful with this option - its behavior is changing in time and the logic is not that plain as it seems.
I would suggest running it as a separate test so far in addition to default strategy to compare results.

[furtib]

I also found that it's not that simple. Despite my suspicion that networking is disabled inside the sandboxed version, testing it on the Bazel native FOSS test branch (#235) (after removing local=true), the tests passed.
I also had my doubts about whether Bazel inside Bazel calls inside the sandbox are possible, but surprisingly they also worked.

If we add this as a second test, should we require that all tests pass this way too, or do you think that would be too flaky?