fix: Resolve differences betweenjax_backend.concatenate and other backends

[phinate]

Resolves part of the jax component for #1654.

This should make the behaviour consistent with numpy, e.g. when using a list as input. The perf slowdown in the trivial case (input == jax array) is on the order of µs on my machine (8 core mbp) with an example 1D array of size 10.

I made this PR purely for syntactical consistency -- of course, the slightly neater way may be to just always cast sequence-type inputs to tensors explicitly, so this isn't a hidden detail.
I couldn't think of a way to best test this consistency in the scope of this PR; if there was a suite that tested the output of common ops, then it fits nicely in there, but AFAIK you only test the core pyhf functionality instead.

Checklist Before Requesting Reviewer

• Tests are passing
• "WIP" removed from the title of the pull request
• Selected an Assignee for the PR to be responsible for the log summary

Before Merging

For the PR Assignees:

• Summarize commit messages into a comprehensive review of the PR

[phinate]

@kratsg thoughts on ths type of approach?

[phinate]

Explaining the current CI failures:

there are cases when doing stitches where this type of encounter is had:

jnp.concatenate((jnp.array([]), jnp.array([3])))
> DeviceArray([3.], dtype=float64)

but this fails if you cast the input to an array.

The actual thing that would fix this PR is casting the elements of sequence to arrays, but my naive implementation of that involves a for loop, e.g.

return jnp.concatenate([jnp.asarray(s) for s in sequence], axis=axis)

which obviously incurs a noticable slowdown.

[phinate]

I can directly address the issue with

return jnp.concatenate(jnp.array(tuple(filter(lambda item: len(item) != 0, sequence))))

which is around 3 times faster, but this is still 10000x slower than numpy :/

Any suggestions here? do we go the long-winded approach of looking at every concatenate instance and making sure it's jax-friendly individually?