add support for multi pagination

[gryphonmyers]

A common use case is to iterate over more than one data set, and generate routes for all combinations between those sets. For example, if I am rendering a set of articles in a set of locales, it might look something like:

locales: ['en-US', 'de-DE', 'zh-TW']
articles: ['article-1', 'article-2', 'article-3']

/en-US
  /article-1
  /article-2
  /article-3
/zh-TW
  /article-1
  /article-2
  /article-3
/de-DE
  /article-1
  /article-2
  /article-3

At present, 11ty only indirectly supports this pattern. The burden of combining the data falls to the user, as described in #1412. This PR seeks to address that issue by adding full support for multiple pagination.

The API involves supplying pagination as an array of pagination objects. This allows us to cleanly support all existing pagination features with full backward compatibility. If a pagination array was supplied, the pagination in the data object will also be an array, with each pagination object in the array providing context specific to the corresponding data set. This allows for an extremely flexible user experience. Given the example above, I will have pagination context not only for neighboring articles in the same locale, but also neighboring localized versions of the same article.

[cchance27]

Could this be used to take say a data source that gives back categories, and then paginate an array of items based on those categories for instance...

typeData: ["car", "truck"]
vehicleData: [{name: "toyota", type: "car"}, {name: "toyota1", type: "car"}, {name: "toyota", type: "truck"}]

For instance /car/page-2/

Right now I can generate using the 1 per page the first layer of /car/ /truck/ based on the first array's results using the standard pagination of 1, but then breaking down sub-object pagination seems complicated, I take it that's sort of what this is looking to fix?

The issue i saw with the referenced ISSUE, was that it seemed to rely on a 1:1 relation not allowing for generation over 1 size but then multiple per page for a different key