Low-hanging fruits in ktfmt performance #619

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:

• 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 Four calls to Parser.parse cause performance issues #552
• 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
• 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?