Summary

Part of #25693.

This PR replaces several places where macros were being used to generate cast specs for the vstring type with c++ templates. No user-facing changes were made.

Other changes

• In working on this, I added a few checks in various places to ensure that the cast specs were being correctly generated.
• Added a few comments about why 64-bit and 128-bit floats are handled differently than the 16-bit and 32-bit floats
• Fixed an instance where a UnicodeEncodeError could be raised. Previously this was done like this:

PyObject *exc = PyObject_CallFunction(
        PyExc_UnicodeEncodeError, "ss#nns", "ascii", s.buf,
        (Py_ssize_t)s.size, (Py_ssize_t)i, (Py_ssize_t)(i+1), "ordinal not in range(128)");
PyErr_SetObject(PyExceptionInstance_Class(exc), exc);
Py_DECREF(exc);

but in using ss#nns, PyExc_UnicodeEncodeError expected a string and buffer length for the second and third arguments. I've changed this to sOnns, to accept a bytes object containing the offending data.

Notes

• In swapping over to templates, it was helpful to add a few new functions that mapped numpy types to names, shortnames, and PyArray_DTypeMeta structs. I'm not sure if there is a better way to do this, but if you have any ideas about this I'd be grateful to learn how this could be done more elegantly (or if these would make sense to have in a different place in the code - I could see them being useful in more places than just this...):

1. typenum_to_shortname_cstr - I realize not all NPY_TYPES have corresponding shortnames, but these were the ones necessary to finish this effort
2. typenum_to_cstr
3. typenum_to_dtypemeta

• C++ is a bit more picky about a few other things that are unrelated to the macros, so I fixed those as well:
  • Variables of type char can't be initialized with string literals
  • Some cases where integer types were being compared to enum types or size_t
  • Cases where enum flags were being combined with |, e.g. NPY_METH_NO_FLOATINGPOINT_ERRORS | NPY_METH_REQUIRES_PYAPI is not of type NPY_ARRAYMETHOD_FLAGS, it is of type int. Explicit casts were added to ensure the correct type
  • There was one instance where a goto was jumping over a variable initialization, which isn't allowed by the cpp compiler. The instance was modified to work without the jump.

@ngoldbaum I noticed that the string to f128 cast has only the NPY_METH_NO_FLOATINGPOINT_ERRORS array method flag. But if you look at string_to_float, or string_to_float_resolve_descriptors, it looks like there are lines that are accessing python objects, calling Py_INCREF, etc. I've kept the array flags identical to how they were before, but should this also have a NPY_METH_REQUIRES_PYAPI flag as well?