BHV-19877: List delegate refactoring and cleanup

Dating back to the original Moonstone release, DataList and
DataGridList would generate list pages twice when resetting. This
was done to ensure that the space taken up by moon.Scroller's
scroll columns was accounted for by the page-generation and layout
code in the list delegates.

We now want to avoid doing the 2x page generation in Moonstone,
but that requires some refactoring in Enyo. Specifically, in the
vertical grid delegate:

* We factor the calculation of grid metrics out of updateBounds()
  and into a new calculateMetrics() method so that it can be called
  independently.

* We also move the invalidation of page metrics from
  controlsPerPage() to didResize() to fix an issue that was exposed
  by the changes described above. This invalidation logic was
  recently added to fix a problem specific to resizing; it seemed
  that controlsPerPage() was the most logical place to implement
  this logic, but it turns out that invalidating the metrics there
  violated some assumptions in the delegate's page-positioning
  logic, so (at least for now) we will be less aggressive about
  invalidation.

* We consistently access the list's width via the delegate's
  width() method, rather than referencing boundsCache directly as
  we had been doing in some cases. This change allows subkinds to
  reliably override the calculated width (which Moonstone's
  delegate needs to do).

And in the base vertical delegate, we make two changes that are not
directly related to the 2x page generation issue, but address
issues that surfaced while investigating and fixing that issue:

* We add a scrollTo() method, similar to the recently added
  scrollToControl() method, which lets subkinds of the delegate
  override scroller options without having to override a lot of
  other logic. Moonstone needs this to prevent unwanted animation
  when scrolling to the beginning of the list in reset().

* We add a forceUpdate argument to controlsPerPage().
  controlsPerPage() tries to avoid unnecessary work by only
  updating if the list's bounds have changed since the last update
  occurred; however, in the vertical grid delegate,
  controlsPerPage() depends not only on the list's bounds but also
  on the grid's calculated layout metrics (e.g. the number of
  columns), so the optimization in controlsPerPage() was preventing
  necessary updates in some cases.

Enyo-DCO-1.1-Signed-Off-By: Gray Norton (gray.norton@lge.com)
When index is 1 and there is no data, page.start is -1 and page.end is -1. This makes one loop below which is creating 1 item. If app is try to get model in this case, it is fail.
When index is 1 and there is 3 items, page.start is 2 and page.end is 2. This makes one loop on page 1 which doesn't have model. This will result in create one dummy item on second page which is not shown.
I don't know the reason of this change of Math.min but the fix can be reverting this line.
@graynorton Do you have a specific reason for this change?