Refactor consecutive transfer hooks

[frangio]

Resolves #3739

In #3739 we realized that the introduction of ERC721Consecutive results in a breaking change, not because the behavior of a contract changes, but because it may stop compiling due to new required disambiguating overrides. An example is the combination of ERC721+ERC721Pausable, or ERC721+ERC721Enumerable, even though these combinations don't involve ERC721Consecutive the user still has to write a disambiguating override for _beforeConsecutiveTokenTransfer.

This understandably results in confusion. This is a proposal for an alternative way to design the hooks, which gives in to the breaking change but with an arguably less disruptive result. The idea is to reuse _beforeTokenTransfer but add a new argument, so that the signature becomes _beforeTokenTransfer(address from, address to, uint firstTokenId, uint lastTokenId). Thus, the same hook is reused for simple and consecutive token transfers. A user that updates the dependency to 4.8 "simply" has to add the new lastTokenId argument to get their contract to compile, and as long as they don't use ERC721Consecutive they can ignore that argument.

This PR is incomplete and won't compile, but I wanted to get the idea out since this is blocking the release of 4.8. I personally think this is an important thing to consider. The effect of having consecutive-related overrides in a contract that doesn't use ERC721Consecutive is not nice at all, and I think it just shows that the design needs to be improved.

We could also consider adding uint size instead of uint lastTokenId as the new argument to the hook.

(Related to #3744)

[frangio]

This needs better documentation.

[Amxx]

LGTM