v0.3.5

What's Changed

• Performance by Include dependency graph by @Jolanrensen in #45

Full Changelog: v0.3.4...v0.3.5

• Doc processors can now run in parallel (enabled by default in TagDocProcessor with canProcessParallel). This is disabled for @include to prevent concurrent modifications.
• Include can now pre-sort docs (can be disabled by setting the argument INCLUDE_DOC_PROCESSOR_PRE_SORT to false) before running. This analyses the docs in O(n), creates a dependency graph which then outputs an order in such a way that each doc can be rendered in one go, O(n) again. This is different from before where some parts of text could be processed multiple times. In practice or with smaller code bases, the performance could be worse with pre-sorting (as all docs now have to be analysed twice), but in larger code bases you might notice a difference.
• Generating a dependency graph is done by IncludeDocAnalyzer, a TagDocAnalyser which is the same as a TagDocProcessor but without changing the docs.
• Added speed indicators to the lifecycle of the gradle plugin.
• The most interesting part now is the IntelliJ plugin. I wanted to have support for the "rendered docs" feature of IntelliJ which could display, well, rendered docs right next to the code. However, since the plugin works one doc at a time, this very quickly became very slow. So, I changed DocumentablesByPathWithCache to an advanced caching system, taking track of changes in a doc + doc @include dependencies with a dependency graph again. I cache both the doc content results (the final rendered doc), as well as a post-include state. This post-include state cache is to prevent deep @include paths with many queries and just overall less work, similar to pre-sort for the gradle plugin.
  The result is a way faster experience, especially when you're not modifying code (it can just load the cache) and, when "Render all doc comments" is enabled, you can modify one doc and see (relatively) live results in docs dependent on it!