Say that Style.PALANTIR is a deprecated alias of OJF

openjavaformat/open-java-format#200 keeps Style.PALANTIR as a
deprecated alias of Style.OJF that formats the same, so code that names
it, or looks the style up by name, keeps working after the change of
coordinates. Migrate now says so, and that up to 21.0.1 such code does
not compile, or fails with NoSuchFieldError when it was built against
palantir-java-format.

To merge with the release that has the alias: until then the page would
promise what the published formatter does not do.

Author: abashev

docs/migrate.md

@@ -86,7 +86,7 @@ The Java packages are unchanged as well. Only the names in your build and your s
 | Gradle plugin | `com.palantir.java-format` | `dev.openjavaformat.java-format` |
 | Gradle property | `palantir.native.formatter` | `openjavaformat.native.formatter` |
 | Command-line style flag | `--palantir` | none: there is one style |
-| Style in the API | `PALANTIR` | `OJF` |
+| Style in the API | `PALANTIR` | `OJF`, with `PALANTIR` as its deprecated alias |
 | IntelliJ plugin | `palantir-java-format` | `open-java-format` |
 | Java packages | `com.palantir.javaformat.*` | the same |
 
@@ -129,6 +129,11 @@ Change the coordinates. The imports stay as they are, because the packages did n
 
 In a `pom.xml` it is the same change of `groupId`, `artifactId` and `version`.
 
+Code that names `Style.PALANTIR` keeps working: it is a deprecated alias of `Style.OJF` and formats
+the same, and `Style.valueOf("PALANTIR")` finds it too. Up to 21.0.1 there is no `PALANTIR`: such
+code does not compile, and a jar built against palantir-java-format fails with `NoSuchFieldError`.
+Change it to `OJF` there.
+
 ### Spotless
 
 With Gradle, remove `palantirJavaFormat()` from the `spotless` block and apply our plugin, which adds