BUG: Minimize iterator size in gufunc allocation of output arrays

Closes #4442 (or at least mitigates it)

Prior to this PR, the iterator created by a gufunc had all core dimensions
of all output arguments appended to the broadcasted non-core dimensions.
When working with gufuncs with multiple return arguments, this would lead
to "iterator is too large" errors.

This PR changes that mechanism, and now each distinct core-dimension is
appended only the maximum number of times that it comes up in an output
argument's signature.

As an example, take #4442, which was failing in a call to SVD with
signature `(m,n)->(m,n),(n),(n,n)`. The iterator was created with shape
`(m,n,n,n,n)` (all output arguments' core dimensions), and then the
`op_axes` for each of the three output parameters were set to
`[0, 1, -1, -1, -1]`, `[-1, -1, 0, -1, -1]` and `[-1, -1, -1, 0, 1]`. After
this PR, in this same case the iterator has shape `(m, n, n)`, and the
`op_axes` now are `[0, 1, -1]`, `[-1, 0, -1]` and `[-1, 0, 1]`.

The only concern is that a function with e.g. signature `(a,b)->(b,a)` would
have had its output created with an iterator of shape `(b, a)` and `op_axes`
set to `[0 ,1]`. Now it will be created with shape `(a, b)` and `op_axes` set
to `[1, 0]`. Not sure if it will result in a different memory layout of the
allocated array.