RFR: [WIP] 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed [v8]

[Johan Vos]

> When the size of a ListCell is changed and a scrollTo method is invoked without having a layout calculation in between, the old (wrong) size is used to calculcate the total estimate. This happens e.g. when the size is changed in the `updateItem` method.
> This PR will immediately resize the cell and sets the new value in the cache containing the cellsizes.

Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into 8277785
 - Precalculate size of cells that are likely going to be used in rendering.
   This avoid resizing cells after their position has been laid out, leading
   to misalignments.
   Relaxed some tests that check on the number of invocations on updateItem.
   We heavily use the accumcell for calculating sizes, and that cell is released
   every time, leading to a call to updateItem as well (but this call should
   not do any CPU intensive work)
 - Try to keep visible cells at their original position when improving the estimate.
   This reduces annoying effects when re-layouting cells without relevant changes.
   
   This should not be done when we don't have a valid estimate yet/anymore,
   or when the absoluteOffset is set to infinity (which may happen if the
   position is set to infinity, which is the case in some calls in Skin classes).
 - Don't recalculate estimated size while doing a layout cycle.
   There are a number of paths possible that first calculate an offset/position,
   and later do a layoutChildren pass. The offset/position calculations (e.g.
   in scrollTo calls) assume a specific estimatedSize. If that size is changed
   between the first call and the layoutChildren logic, the result will not look
   as intended.
   Hence, we should avoid updating the estimated size at the start of the layout
   phase. We can do it safely at the end.
   Thanks to Zeiss and Florian Kirmaier for providing additional tests.
 - Don't shift cells if we are already showing the lowest index cell.
 - Add test to check if there are no empty cells at the end of a List in case there are enough leading cells available.
 - Add the option to shift all cells down in case the current calculations would lead to empty cells at the end of the view,
   while there are available cells before the beginning of the view.
 - resize cell when getting it from the pile, and recalculate total estimated size

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/712/files
  - new: https://git.openjdk.org/jfx/pull/712/files/67b351ac..585119de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=712&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=712&range=06-07

  Stats: 572523 lines in 7576 files changed: 290856 ins; 175331 del; 106336 mod
  Patch: https://git.openjdk.org/jfx/pull/712.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/712/head:pull/712

PR: https://git.openjdk.org/jfx/pull/712