[ refactor ] make n≢i : n ≢ toℕ i argument to lower₁ irrelevant

[jamesmckinna]

PR #2748 made me rethink whether Data.Fin.Base.lower₁ is fit-for-purpose (as an inverse to inject₁), or could instead be deprecated in favour of the new Data.Fin.Base.lower...

This PR doesn't entirely solve that issue, but does prove the two definitions extensionally equal on their domains, as a consequence, perhaps more importantly, of weakening the type of lower₁ so that its precondition is made irrelevant.

Two (possibly more downstream) knock-on consequences:

• lemma lower₁-¬0≢0 : ∀ {ℓ} {A : Set ℓ} → .(0 ≢ 0) → A encapsulates a repeated pattern of (¬-recompute) reasoning, which ideally would be made private, but is needed in both Base and Properties... so, reluctantly, has been added; avoided in favour of [ refactor ] weaken type of Relation.Nullary.Negation.Core.contradiction-irr #2785 on which this PR is now blocked.
• many of the proofs about lower₁ could/should be simplified by delegation to those for lower...?
• [ refactor ] make i ≢ j argument to Data.Fin.Base.punchOut irrelevant #2790 Data.Fin.Base.punchOut and its properties could similarly be weakened by making its i≢j : i ≢ j argument irrelevant! What else might be susceptible to this kind of refactoring?

NB. As observed/observable in README.Data.Fin.Relation.Unary.Top, we can actually avoid having any uses of lower₁ in the library, so deprecation seems possible/desirable #2786

UPDATED: no longer blocked on #2785 .

[JacquesCarette]

Modulo my comment on whether we even need those extra 2 lemmas, I'm now happy with this.