Fix/cargo deny advisories

[elizabethengelman]

What

• Update openssl to 0.10.72 per cargo deny advisories suggestion
• Update tokio to 1.42.1 per cargo deny advisories suggestion

Why

• openssl upgrade to fix this error:

error[vulnerability]: Use-After-Free in `Md::fetch` and `Cipher::fetch`
    ┌─ /Users/ebethme/Desktop/projects/stellar/stellar-cli/Cargo.lock:281:1
    │
281 │ openssl 0.10.70 registry+https://github.com/rust-lang/crates.io-index
    │ --------------------------------------------------------------------- security vulnerability detected
    │
    = ID: RUSTSEC-2025-0022
    = Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0022
    = When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result.

      In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior).

      The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.
    = Announcement: https://github.com/sfackler/rust-openssl/pull/2390
    = Solution: Upgrade to >=0.10.72 (try `cargo update -p openssl`)

• tokio upgrade to fix this error:

    ┌─ /Users/ebethme/Desktop/projects/stellar/stellar-cli/Cargo.lock:470:1
    │
470 │ tokio 1.39.2 registry+https://github.com/rust-lang/crates.io-index
    │ ------------------------------------------------------------------ unsound advisory detected
    │
    = ID: RUSTSEC-2025-0023
    = Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0023
    = The broadcast channel internally calls `clone` on the stored value when
      receiving it, and only requires `T:Send`. This means that using the broadcast
      channel with values that are `Send` but not `Sync` can trigger unsoundness if
      the `clone` implementation makes use of the value being `!Sync`.

Known limitations

N/A