[Bug] `PendingTransactionBuilder::get_receipt` should watch for dropped transactions

### Component

provider, pubsub

### What version of Alloy are you on?

Latest

### Operating System

None

### Describe the bug

Currently, `PendingTransactionBuilder::get_receipt` would be stuck if submitted transaction gets dropped by the node.

I believe this bug is high-impact, since [it causes `cast` to hang](https://github.com/foundry-rs/foundry/blob/master/crates/cast/src/lib.rs#L852) under certain circumstances.

You can reproduce it as follows:

1. Run `anvil`
2. Run `cast send --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 0x3333333333333333333333333333333333333333 --nonce 1 --gas-limit 200000` in 2nd terminal
3. Run `cast send --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 0x8888888888888888888888888888888888888888 --nonce 1 --gas-limit 200000` in 3rd terminal
4. Run `cast send --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 0x976EA74026E726554dB657fA54763abd0C3a0aa9 --nonce 0 --gas-limit 200000` in 4th terminal

This way we will cause one of the transactions with nonce 1 to be dropped, and after we submit tx with nonce 0, only one of cast instances will finish. Another one will be left hanging indefinitely.

Additionally, `get_receipt` implementation currently contains a [hotfix for preventing race condition](https://github.com/alloy-rs/alloy/blob/main/crates/provider/src/heart.rs#L244), but it looks like it doesn't respect `required_confirmations` (looks like we'll return here as soon as receipt is available, regardless of number of required confirmations).