Fix remaining auxilliary class warnings in Solr

We have quite a number of situations where multiple classes are declared in a single source file, which is a poor practice. I ran across a bunch of these in solr/core, and mdrob fixed some of these in SOLR-14426. dsmiley looked at those and thought that it would have been better to just move a particular class to its own file. And uschindler do you have any comments?

I have a fork with a bunch of changes to get warnings out that include moving more than a few classes into static inner classes, including the one Mike did. I do NOT intend to commit this, it's too big/sprawling, but it does serve to show a variety of situations. See: https://github.com/ErickErickson/lucene-solr/tree/jira/SOLR-10810 for how ugly it all looks. I intend to break this wodge down into smaller tasks and start over now that I have a clue as to the scope. And do ignore the generics changes as well as the consequences of upgrading apache commons CLI, those need to be their own JIRA.

What I'd like to do is agree on some guidelines for when to move classes to their own file and when to move them to static inner classes.

Some things I saw, reference the fork for the changes (again, I won't check that in).

1> DocValuesAcc has no fewer than 9 classes that could be moved inside the main class. But they all become "static abstract". And take "DoubleSortedNumericDVAcc" in that class, It gets extended over in 4 other files. How would all that get resolved? How many of them would people recommend moving into their own files? Do we want to proliferate all those? And so on with all the other plethora of classes in org.apache.solr.search.facet.

This is particularly thorny because the choices would be about a zillion new classes or about a zillion edits.

Does the idea of abstract .vs. concrete classes make any difference? IOW, if we change an abstract class to a nested class, then maybe we just have to change the class(es) that extend it?

2> StatsComponent.StatsInfo probably should be its own file?

3> FloatCmp, LongCmp, DoubleCmp all declare classes with "Comp" rather than "Cmp". Those files should just be renamed.

4> JSONResponseWriter. ???

5> FacetRangeProcessor seems like it needs its own class

6> FacetRequestSorted seems like it needs its own class

7> FacetModule

So what I'd like going forward is to agree on some guidelines to resolve whether to move a class to its own file or make it nested (probably static). Not hard-and-fast rules, just something to cut down on the rework due to objections.

And what about backporting to 8x? My suggestion is to backport what's easy/doesn't break back-compat in order to make keeping the two branches in sync.