feat: paginate without counting the collection

[kbond]

Refs #51.

Page needed the total to answer even basic questions - nextPage() went through lastPage() → totalCount() → count(), so a previous/next pager paid for a COUNT over the whole table. It now fetches one item more than fits on the page and uses that extra item's presence to answer the new hasMorePages(), discarding it before you see the items. nextPage(), previousPage() and haveToPaginate() are all derived from it.

totalCount(), lastPage() and pageCount() are unchanged - they still count, but only when called. So a previous/next pager counts nothing, and a numbered one counts once.

Strict mode got the same treatment: it used to count on every request to validate the page number, and now fetches the requested page first and only counts if that page came back empty. A valid page costs nothing extra; the fallback is paid for only when the requested page really is out of range.

For #51 specifically: @jungleman12's exact usage (paginator.nextPage and paginator|length over 2M rows) now runs no COUNT at all, and @seb-jean's diagnosis in that thread was exactly right - the nextPage() → lastPage() → totalCount() chain is what's gone. What this does not fix is the OFFSET cost you already called out there: deep pages still make the database walk and discard rows. That's still #52's territory, so I left this as a reference rather than a fix.

Also adds Pager/_simple.html.twig and Pager/_full.html.twig for rendering either mode against a plain Page, and Twig becomes a dev dependency so they're actually rendered in tests.

Behavior change: nextPage() returns null for a page past the end where it previously returned the next page number (paginate(page: 999) on an 8-page collection used to report 1000). Two existing assertions covered that and were updated.