IterativeSolvers: accept LinearSolve's maxiters spelling on the algorithm

[AJ0070]

Fixes #175.

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

• LinearSolve spells the iteration cap maxiters, IterativeSolvers spells it maxiter. Setting it on the algorithm, as the issue does with IterativeSolversJL_CG(maxiters = 100), forwarded an unknown keyword straight through and failed with a MethodError. The issue's own workaround was to drop the s.
• maxiters is now accepted as an alias on the algorithm. An explicit maxiter wins if both are given, and the resolved value is threaded through every branch, including idrs_iterable! and bicgstabl_iterator! which take the cap positionally, so an algorithm-level value actually takes effect instead of being quietly replaced by the cache's.
• Verified it caps rather than merely not throwing: maxiters = 2, 5 and 25 stop after exactly 2, 5 and 25 iterations, maxiter = 3 is still honoured, and with both given maxiter wins.
• One thing the cross-check caught: renaming the key broke BICGSTAB, because bicgstabl_iterator! caps work through max_mv_products and has no maxiter keyword at all, so the normalized name reached a function that cannot accept it. It is stripped for that branch. Testing only the algorithm from the issue would have fixed four solvers and broken a fifth.
• All five IterativeSolversJL_* variants solve correctly, bare and with maxiters, 10 of 10 combinations.
• Tests cover every variant with maxiters, that the cap is respected, and the maxiter precedence rule. The existing testset only ever passed gmres_restart, so it could not have caught this.
• Full GROUP=Core suite passes with zero failures. Runic clean.

AI Disclosure: Used Opus 5