Refactor the pagination gem once Resource engine is default

[jaredcwhite]

The pagination gem largely contains code ported from a third-party gem written for Jekyll, and even though I've made a number of enhancements/performance fixes since adding it in, a lot of it is still pretty crufty and not very Ruby-like IMHO (aka lots of linear procedural-style code and very long methods).

Once the Resource engine reigns supreme, I'd like to start pretty much from scratch and ensure the pagination subsystem is well-written, performant, and easily hooks into new Resource features like taxonomies. There are also some funky things around how it current handles permalink and file path outputs we could clean up.

[jaredcwhite]

Architectural note: this could be a perfect candidate for using Signalize. Essentially we could spin paginators up freely wherever/whenever we want, and the actual list of resources would be lazily computed on-demand. When you think of it, a paginator is really just a filtering mechanism/lens, and it could become a first-class part of Bridgetown's model layer rather than something which runs under the hood largely hidden from view.

[jaredcwhite]

Ooo, another thought: a "paginator" is just the thing that carves [1,2,3] into [1,2] + [3], and what you're actually paginating is in fact either a standard collection or a "smart collection" — a smart collection being literally any array of resources which would match the filtering criteria and could be sourced from multiple collections at once.