Define an upper bound on number of concat inputs and split outputs

[philloooo]

In the same spirit as #928, do we need to allow splitting/concatting up to 2**32 tensors?
Is there a more reasonable lower upper bound?
@fdwr curious to learn from your model experience.

in this CL we are fuzzing just 1-10 inputs for split

[fdwr]

In practice, I've never seen more than a few hundreds of outputs. Granted, 2³¹ - 1 split outputs or 2³¹ - 1 concat inputs would likely exceed some other resource/JS object creation limit before even reaching the backend.

Interestingly, unlike the previously proposed limits which were more about element counts and dimensions, this limit is more about capping the total number of tensors linked to an operator, which isn't a limit category we've considered yet. Though, there is implicitly already a limit of 2³¹ - 1 tensors (less than the uint32 split count of 2³² - 1) since you can't split a tensor into more parts than there are input elements, and the largest possible input is a 1D tensor 2³² - 1 of elements split into billion of scalars.