Update scalafmt-core to 3.10.4 (#611)

* Update scalafmt-core to 3.10.4

* Reformat with scalafmt 3.10.4

Executed command: scalafmt --non-interactive

* Add 'Reformat with scalafmt 3.10.4' to .git-blame-ignore-revs

Author: scala-steward

.git-blame-ignore-revs

@@ -0,0 +1,2 @@
+# Scala Steward: Reformat with scalafmt 3.10.4
+883877c6379365097aaf129bfb37b859ce4a154b

.scalafmt.conf

@@ -1,4 +1,4 @@
-version = 3.10.3
+version = 3.10.4
 runner.dialect = scala36
 maxColumn = 100
 align.preset=none

crunchy-protoc-plugin/src/main/scala/eu/neverblink/protoc/java/gen/Preconditions.scala

@@ -158,24 +158,24 @@ object Preconditions:
   /*
    * All recent hotspots (as of 2009) *really* like to have the natural code
    *
-       * if (guardExpression) {
+   * if (guardExpression) {
    *    throw new BadException(messageExpression);
    * }
    *
-       * refactored so that messageExpression is moved to a separate String-returning method.
+   * refactored so that messageExpression is moved to a separate String-returning method.
    *
-       * if (guardExpression) {
+   * if (guardExpression) {
    *    throw new BadException(badMsg(...));
    * }
    *
-       * The alternative natural refactorings into void or Exception-returning methods are much slower.
+   * The alternative natural refactorings into void or Exception-returning methods are much slower.
    * This is a big deal - we're talking factors of 2-8 in microbenchmarks, not just 10-20%.  (This
    * is a hotspot optimizer bug, which should be fixed, but that's a separate, big project).
    *
-       * The coding pattern above is heavily used in java.util, e.g. in ArrayList.  There is a
+   * The coding pattern above is heavily used in java.util, e.g. in ArrayList.  There is a
    * RangeCheckMicroBenchmark in the JDK that was used to test this.
    *
-       * But the methods in this class want to throw different exceptions, depending on the args, so it
+   * But the methods in this class want to throw different exceptions, depending on the args, so it
    * appears that this pattern is not directly applicable.  But we can use the ridiculous, devious
    * trick of throwing an exception in the middle of the construction of another exception.  Hotspot
    * is fine with that.