User-defined dtype: Can be confusing to know which conversions to provide for compatibility with core methods

[EricCousineau-TRI]

Relates #8952, #8860
Same campaign as #10721, #10897

When defining user-defined dtypes (using the C API), it can sometimes be a tad confusing to know which conversion to provide to ensure the underlying machinery works properly.

For example, the implementation of np.ones relies on on the following operation:

multiarray.copyto(a, 1, casting='unsafe')

When debugging, it was a tad confusing to know whether to define a conversion for np.int64 or np.int or something else. (I had gotten distracted by pybind/pybind11#1328 - still need to finish out the related PR and test it out.)

Additionally, for identity values for reduction and such, it's also confusing.

I found that np.trace was also a tad sticky; after defining conversions for double -> my custom dtype, np.trace would still fail to find a conversion, even though I had an override defined for np.add for my custom dtype. After digging, it seems that the assign_identity_* functions relied on bool casting (PyUFunc_GenericReduction -> ... -> PyUFunc_ReduceWrapper -> assign_reduce_identity_zero -> ... -> get_cast_transfer_function).
Post-#8952, it seems that now the proper conversion to define would be (int -> Custom).
(To clarify, I'm not knocking the fix, it does seem like an improvement! I have no issue with defining conversions from both bool and int.)
(As a side note, also relates #9351 in < v1.14.0: since no overrides were found, it looped.)

That being said, it would be nice if there were hints in the documentation somewhere for compatibility with core NumPy functions; that, or at least some comments in test_rational.c.src explaining some of these heuristics?

\cc @eric-wieser @njsmith