Core: switch to Lucene QueryRescorer

Simon started this with #6232 and I just simplified it a bit ...

One functional change I did was: if a first pass hit did not "participate" in rescoring (because it wasn't in the top window hits), I multiply its score by rescore.queryWeight() matching what we do when it did participate but the 2nd pass query didn't match it.  I'm not sure that's "correct" but I think it's "more correct" than just using the raw first pass score ...
> Not sure I agree here, isn't the bug rather that we should only sort up to resorted.scoreDocs.length (and maybe force the weight of the first-pass query to be gte 1)?

It's tricky ... because if you only sort resorted.scoreDocs.length then the hits are not necessarily properly sorted by score?  I mean, a hit in the non-rescored part could in theory have a higher score than the rescored part?

But you're right, pagination won't work right, if you increase size across the two requests.  Maybe we should document that you cannot change size?  E.g., you can only show up to N pages and you query up front for page=1 for all N pages...

> For the same reason I think another bug is that rescoring should take into account the offset (it doesn't seem to)?

Hmmm... that's a great question.  At what point is from/offset applied when rescoring?  Hopefully it is after rescoring ran.  I'll try to add a test making sure if you change "from" (keeping size constant) it's behaving properly...

Also, do we check/require that you can only run rescorer if you are sorting by score in the first place...