Miscellaneous matrix maintenance

[fredrik-johansson]

A list of issues I've noted while preparing #2162.

• ungodly amounts of code duplication: move duplicated mat, poly and poly_factor code to generics ASAP
• solve / can_solve / gr_mat_solve_field methods were previously creating a row-permuting window matrix but after # 2162 create a copy; here, we could still use a shallow matrix over non-shallow ground types; also can check if permutation is the identity and then don't create a copy
• when permuting rows, use less temporary space (can proceed in slices, e.g. rows x 64 -- done for nmod_mat, do this for gr also)
• gr_mat_rank is not using the good algorithm over finite fields
• add XXX_mat_row(mat, i) (pointer to start of row i) and XXX_mat_col(mat, i) (pointer to start of column i) helper functions for matrix types
• add methods to access the stride
• d_lll, mpf2_lll: perform shallow row moves (4 places)
• perm function in nmod_mat tests -> replace by nmod_mat_permute_rows?
• several Brent-Kung implementations don't take advantage of squaring when computing successive powers
• fmpz_mat_get_nmod_mat - is the check for symmetry really worth it here? (and if it is, should we do the same in many other places?)
• various compose_mod_brent_kung methods: avoid creating the temporary Arows
• reimplement arb_mat/acb_mat approx methods by wrapping arf/acf+gr
• threaded classical multiplication (e.g. nmod_mat_mul_classical_threaded, fmpz_mod_mat_mul_classical_threaded, arb_mat_mul_threaded) should be done in a simpler, generic way
• can skip tmp in solve_tril/triu with strided dot?
• use strided dot products in various places
• optimizations everywhere for stride == c by doing vec_op(..., r * c) instead of r times vec_op(..., c) (add, set, equal, max_bits, etc.)
• arb_mat_vector_mul_col etc. why always create a copy?
• introduce FLINT_COPY / FLINT_COPYI / FLINT_COPYD macros to get rid of memcpy? maybe also FLINT_VEC_SWAP
• squaring optimizations in mul_blas
• should fmpz_mat_det_bound_inner use fmpz_vec_dot? (I forget if it's optimized for squaring)
• fmpz_mat_equal_col / fmpz_mat_equal_row could take two matrices to be more general?
• _fmpz_mat_resize_van_hoeij (two of these) -> proper fmpz_mat_resize method
• create proper _nmod_mat_pivot/nmod_mat_pivot (exist multiple)
• use nmod_mat_permute_rows or similar in lu_recursive
• more high level mat_similarity