Sometimes use canonical names and simple names instead of binary names for classes.

[copybara-service]

Sometimes use canonical names and simple names instead of binary names for classes.

Terminology refresher:

• binary name name: com.google.Foo$BarException (though I seem to recall learning from the prospective reviewer of this CL that there's a second kind of "binary name," probably using / instead of .?)
• canonical name: com.google.Foo.BarException
• simple name: BarException

Specifically, we use simple names only for a set of well-known classes (as opposed to using them everywhere), and then we try canonical names, falling back to binary names when we have no other option (e.g., anonymous and local classes).

Advantages:

• Binary names are annoying to read, especially when multiple appear on the same line (as can happen in IterableSubject failure messages, for example).
  • Array binary names are particularly bad: [Ljava.lang.Long; (in contrast to java.lang.Long[] or just Long[]).
• A search for a binary name in Code Search doesn't find it.
• Java and Kotlin disagree on how to spell types like Long: Is it java.lang.Long or kotlin.Long?
  • We can't fully dodge this with Integer/Int and Character/Char, but we can at least avoid mentioning "Java" and "Kotlin" for users who might not think of themselves as using one of those things.
• We can output simple names even when we lack class metadata under J2CL.
• This is arguably consistent with how we already have special code to output "Map.Entry" in SubjectUtils.

This CL requires that I change SubjectUtils.java to actually use its own longName method in one place. I had missed this in cl/773872316.