Low-hanging fruits in ktfmt performance

Hey, while we are waiting for #616, it would be nice to get accustomed to the code base and contribution policy, send a few patches, and see how it goes in general. Improving performance without significant architectural changes seems to be a nice place to start!

So far, things I've found that can be done relatively easily:

* [x] Reuse `Parser.parse` result if code wasn't changed between formatting steps. The duct-taped version of this change yields ~20-25% of raw throughput. Duplicate of #552
* [x] `Parser.parse` visits `KtFile` in search for parsing errors, basically parsing it two times in a row. ~10-15% when commented out (which is not an option for a fix, but an approximation), probably a much less straightforward fix though
* [x] Avoid redundant allocations where appropriate -- mostly comes from eager materialization of `PsiElement.text` here and there
* [ ] Avoid substringing every line four times in `getMultilineTrimmedStringList` (because of `lines()`). Less generally-applicable, helps a lot for large files with `trimIndent`/`trimMargin` (~25% on `kftmt`, mostly because of `FormatterTest.kt` which is exactly this pattern)
* [ ] Avoid all the extra work in `MultilineStringFormatter` when there are no `"""` and/or `trimIndent`/`trimMargin`. ~10-15%?

Note: performance numbers are from runs on kotlinx.* libraries in sequential mode (with commented out `parallelStream`), parallel mode is too noisy for measurements.

Would you be okay if I gradually start sending patches for these and add @AbdullinAM as a co-reviewer?

Start by reading getMultilineTrimmedStringList and MultilineStringFormatter, then inspect how Parser.parse is used. Benchmark sequential formatting on the kotlinx.* libraries described in the issue, focusing on large files using trimIndent or trimMargin; done means reducing the listed redundant work without significant architectural changes.

Written by the indexing model from the issue text.