Goal: Stop being non-compliant with OCI when it comes to paginating tag lists.

Why is this important: Quay(.io) currently uses custom implementation using the RFC5988 standard to paginate the result set of the /v2/<name>/tags/list OCI endpoint, leveraging a token called next_page containing an encrypted, time-limited token containing the database row identifier of the last tag in the result set. While several clients have adopted this, this is not covered by the current OCI listing spec: https://github.com/opencontainers/distribution-spec/blob/v1.0/spec.md#content-discovery 

As a result, clients have to implement specific support for either our next_page parameter or respect the Link header, which should not be required as per the OCI spec.

Required deliverables:

• Support the n parameter as per the OCI spec to drive the amount of tags per page
• Support the last parameter, as a way to drive the tag pagination
• Raise HTTP 413 TAG_LIMIT_EXCEEDED as proposed in https://github.com/opencontainers/distribution-spec/pull/470 if n is higher than our configured maximum amount of tags per page in Quay
• Continue to support the existing next_page parameter to retain backwards compatibility
• The amount of maximum tags per page configured in Quay has to minimally be 100