Parallelizing Gobra

[ArquintL]

This PR introduces several optimizations to Gobra:

• Parallel parsing
  • A "fast parser" (ANTLR parsing the 'preamble' of a file) quickly identifies package imports (per file). This introduces some overhead as a file ends up being parsed twice. I see quite a variance for parsing this preamble ranging from <1% to 50% of the time it takes to parse the entire file.
  • Since I had to re-generate the parser, I've updated to the latest ANTLR release will also required updating the Go lexer and Go parser because the previous lexer and parser caused an error.
• Explicit type-check dependencies
• TypeInfo (i.e. the type-check instance per package) gets a dependentTypeInfo map that maps the package's (direct) imports to the corresponding type-check result.
• Since dependentTypeInfo makes the dependencies for type-checking explicit, this enables us to cache (in memory) type-checking results because we no longer depend on a Context instance that changes for every verification job.
• Parsing and type-checking can be performed lazily, sequentially or in parallel, which is configurable via CLI
• Parallel desugaring
  • Although impact is low (since desugaring is fast compared to other steps performed by Gobra), the main package (i.e. the one that is getting verified) and imported packages are now desugared in parallel
• I've adapted the GobraTests to initially parse and type-check all test cases in parallel. Only afterwards, each test case is executed (while retrieving the parse AST and type info from the caches). On my machine, this gives a 20% speedup for executing the test cases. This behavior can be easily disabled by a corresponding flag in GobraTests, e.g., for debugging purposes.

[Felalolf]

I did not look at the Parser and Info in detail. I would need more time to look at that. Please add some more documentation to each of the jobs that gives an overview of what the job is doing, in particular before the ParseJob trait and TypeCheckJob.