kernel: don't use ProdIntObj as ProdFunc; use PowObjInt less

[fingolfin]

We used to install ProdIntObj and PowObjInt for a large variety of TNUMs,
including precords, functions, strings etc., where they never made sense:

And for those TNUMs where it did make sense (e.g. T_RAT), often later modules
would install more specialized functions anyway. For ProdIntObj, this meant
that the only sensible place it was used was for T_MACFLOAT. This PR removes
even that, though, since it was only used for int * float, but not for
float * int, which resulted in the two behaving differently:

gap> 10^400 * 10.^-300;
1.e+100
gap> 10.^-300 * 10^400;
inf

Hence, we stop using ProdIntObj as kernel level ProdFunc completely, even for
machine floats, and instead,rely on library functions for multiplying integers
and floats.

Note that ProdIntObj can still be invoked from the library via PROD_INT_OBJ,
and this is used to install default multiplication functions for integers with
IsNearAdditiveElementWithInverse elements (and these method installations are
also provided symmetrically, i.e. intobj as well as objint). While this is
very slightly slower, it is at least guaranteed to be symmetric and
mathematically well-defined.

For PowObjInt, the asymmetry is natural, so less of a problem. Also, it turns
out that it is actually used in a few more cases, e.g. to power
transformations and partial permutations. Still, doing f^1 for a function or
'x'^1 or true^1 are all surprising. To resolve this, we restrict for which
TNUMs we install PowObjInt as PowFunc substantially: We don't use it on all
constant TNUMs anymore, but rather only on those were multiplication by an
integer makes some sense, using the new TNUM range FIRST_MULT_TNUM till
LAST_MULT_TNUM. We also don't install it for records anymore, and also not for
blists and strings. It is kept for ranges and other plists, as there it has a
chance of a well-defined behavior (if the list describes a vector,
possibly a matrix).

[fingolfin]

Some examples of things GAP accepted before this PR (but which trigger an error with it):

gap> 1 * Immutable(rec());
rec(  )
gap> rec() ^ 1;
rec(  )
gap> 1 * 'x';
'x'

[ChrisJefferson]

We should watch for this commit when we run package tests, just in case some package is doing something stupid.