Tidy up tolerance in NekLinSystIter and NekNonlinSysIter solvers

Issue/feature addressed

The main objective of this MR to remove the tolerance argument in v_SolveSystem function call in order to use parameters provided from NekSysKey during construction. This reduce confusion about who is responsible of setting/controlling tolerance and iteration parameters for the linear solvers. Related changes are summarized as follow:

• Remove GetIterativeTolerance and related code from AssemblyMap
• Rename NekNonlinSys as NekNonlinSysIter for consistency
• Rename NekNonlinSysNewton as NekNonlinSysIterNewton for consistency
• Remove virtual functions ConvergenceCheck from NekSys.h base class.
• Add specialized (with specific signature) ConvergenceCheck function to NekLinSysIter.h subclass.
• Add specialized (with specific signature) ConvergenceCheck function to NekNonLinSysIter.h subclass.
• Remove m_maxiter and m_tolerance from NekSys.h base class.
• Add m_NekLinSysMaxIterations and m_NekLinSysTolerance member variable to NekLinSysIter.h subclass.
• Add m_NekNonLinSysMaxIterations and m_NekNonLinSysTolerance member variable to NekNonLinSysIter.h subclass.
• Move m_rhs_magnitude and SetRhsMagnitude from NekLinSysIter.h to NekSys.h base class.
• Remove redundant m_LinSysRelativeTolInNonlin variable.

Proposed solution

A summary of the proposed changes and how they address the issue/feature at hand. Whenever possible, describe alternatives your considered and decisions you made.

Implementation

A more detailed description of the changes. Please include any details necessary for reviewers to understand your work, and point out particular points would like them to pay particular attention to.

Tests

Suggested reviewers

Please suggest any people who would be appropriate to review your code.

Notes

Please add any other information that could be useful for reviewers.

Checklist

• Functions and classes, or changes to them, are documented.
• [ ] User guide/documentation is updated.
• Changelog is updated.
• [ ] Suitable tests added for new functionality.
• Contributed code is correctly formatted. (See the contributing guidelines).
• [ ] License added to any new files.
• No extraneous files have been added (e.g. compiler output or test data files).