RASR FSA join: add explicit dtypes for cumsum

[Icemole]

If we use the default dtype, np.cumsum fails when summing here:

File "...work/i6_core/tools/git/CloneGitRepositoryJob.kJHGZFZS4N14/output/i6_models/i6_models/parts/rasr_fsa.py", line 332, in join_fsas_fbw_v2
    line: f_edges[:2, :] += start_states[idx]
    locals:
      f_edges = <local> array([[ 1,  2,  3,  0,  1,  2,  0,  2,  3,  1,  2,  0],
                               [ 1,  2,  3,  1,  2,  3,  2,  4,  4,  4,  4,  4],
                               [ 3, 14,  3,  3, 14,  3, 14, 14,  3, 14,  3, 14]], dtype=int32)
      start_states = <local> array([  0,   5,  10,  15,  20,  25,  30,  35,  40,  45,  50,  55,  60,
                                     65,  70,  75,  80,  85,  90,  97, 102, 107, 112, 117, 122, 127,
                                    132, 137, 142, 147, 152, 157, 162, 167, 172, 177, 182, 187, 192],
                                   dtype=uint64)
      idx = <local> 0
UFuncTypeError: Cannot cast ufunc 'add' output from dtype('float64') to dtype('int32') with casting rule 'same_kind'

This is because the cumsum dtype is actually np.uint64, and the first common parent of np.int32 (allows negatives) and np.uint64 (2x more range than np.int64 in the positive side) is np.float64. Let me provide an example:

>>> start_states = np.cumsum(np.array([0] + [5, 5, 5], dtype=np.uint32))[:-1]                  
>>> start_states
array([ 0,  5, 10], dtype=uint64)
>>> f_edges = np.array([4, 4, 4, 4, 4, 4, 4, 4, 4], dtype=np.int32).reshape(3, -1).copy()
>>> np.result_type(start_states, f_edges[:2, :])
dtype('float64')
>>> f_edges[:2, :] += start_states              
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
numpy.core._exceptions._UFuncOutputCastingError: Cannot cast ufunc 'add' output from dtype('float64') to dtype('int32') with casting rule 'same_kind'

This PR fixes such an issue with the default cumsum by explicitly setting np.uint32 as default dtype for the cumsum operation.

[Icemole]

I'm not sure why I didn't notice ~2 months ago and now I did. It might have something to do with the somewhat ambiguous default dtype for cumsum:

If dtype is not specified, it defaults to the dtype of a, unless a has an integer dtype with a precision less than that of the default platform integer. In that case, the default platform integer is used.

"Default platform integer" sounds quite ambiguous and prone to issues if one changes the "platform", see e.g. numpy/numpy#9464.

Anyway, now that I have the PR ready and a stable commit to pull from, I'll be testing the implementation with my own training.