Bump ethnum to placate nightly, for unified build, for oss-fuzz (#5287)

The causal chain here is:

- oss-fuzz wants to fuzz with sanitizers turned on (a generally good
idea)
- rust sanitizer builds have to be both unified builds and _nightly_
builds (the sanitizer flag is rust-nightly-only)
  - our rust build depends on `ethnum`, specifically version `1.5.0`
- `ethnum 1.5.0` has a bug in it that our pinned rust `1.95.0` doesn't
mind, but rust nightly rejects; it's
[fixed](nlordell/ethnum-rs#58) in `1.5.3`
- `1.5.3` otherwise seems to work fine and the release notes show only
some optimizations and bugfixes.
- There's some _theoretical_ potential for divergence (eg. where
observable bugs in `ethnum` were fixed:
nlordell/ethnum-rs#44) but .. I don't see any
way for this to actually get hit in practice: this PR is a bump to the
`ethnum` dependency _outside_ any of the soroban production-build deps
(they all have their own pinned ones in production builds) and that
dependency only exists, as far as I can tell, because `stellar-xdr`
links in `ethnum` to be able to do u256/i256 ops, which .. we don't
actually use anywhere in the non-soroban-host rust code (eg. the bridge
helpers). There's no use of `i256`, `u256`, `I256`, `U256`, or `ethnum`
in any rust code in our tree outside the soroban crates. So I don't
_think_ this can cause any divergence in production. But, you know, one
can always miss something!

If that very narrow possible I-don't-see-how risk is still too much to
swallow we can wait for a protocol boundary, but this will I think
basically block oss-fuzz integration until it's resolved.

(There's another option which is to turn off the sanitizers, I guess; I
am going to try that in the meantime to see if I can get it working, but
I'm not sure how likely that is nor whether it's a particularly good
idea longer-term.)

Author: graydon