fix convert_element_type on large Python int inputs

[mattjj]

@jekbradbury noticed that when we call lax.convert_element_type(2 ** 100, jnp.float32), we first convert to int32 when we canonicalize the input dtype. But int32 can't represent 2**100, while a float32 can!

Concretely, before this PR, this fails:

import jax.numpy as jnp
jnp.multiply(2 ** 100, 3.)  # OverflowError: Python int too large to convert to C long

It fails because under the hood it ends up doing this, which also fails:

from jax import lax
lax.convert_element_type(2 ** 100, jnp.float32)

even though this succeeds:

import numpy as np
lax.convert_element_type(np.float32(2 ** 100), jnp.float32)

#6014 caused this to surface in a downstream library, because the special-case logic #6014 removed had effectively called np.array(x, to_dtype) before applying any JAX primitives.

Luckily these issues lead to loud overflow errors from NumPy, rather than a silent loss of bits.

The fix is just to have lax.convert_element_type (i.e. the 'traceable' wrapper) use NumPy to convert Python int inputs to numpy arrays with the target dtype (like a float32), rather than the current behavior of converting to the canonical dtype for the input (like an int32), before transferring the value out of Python and to the device.

I also had to fix up some handling of float0s in host_callback logic. The logic now mirrors the analogous logic in custom_jvp/custom_vjp. I tweaked the implementation of the fix so that these aren't needed anymore. They may still be good changes, but I'd rather keep the PR minimal.