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 ...
> 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?

Maybe we should ensure that the original query weight is greater than 1 and that the rescore weight is greater than 0, so that rescoring can only increase scores? The fact that non-rescored hits could have higher scores than rescored hits feels wrong to me.

> 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...

I wish this is something elasticsearch could take care of by itself, so that
 - given a fixed `window_size` you would have exactly the same hits with the same scores and at the same position, no matter what your `from` and `size` are (this way over-requesting up-front would just be an optimization, not the normal procedure)
 - you could request pages that are beyong `window_size`