[Feature] Support for passing context through filler pipeline

### Component

provider, pubsub

### Describe the feature you would like

Hi, I've been using alloy for a while and really enjoy it. Thanks for all the work on this

My problem:

I'd like to pass additional context alongside a TransactionRequest through the filler pipeline. The solution that I tried first, which run into one or another problem was something like this:

```
#[derive(Debug, Clone, Copy)]
pub struct NetworkWithContext(PhantomData<(N, C)>);

pub struct TransactionRequestWithContext {
pub request: TR,
pub context: C,
}

impl Network for NetworkWithContext {
type TxType = N::TxType;
type TxEnvelope = N::TxEnvelope;
type UnsignedTx = N::UnsignedTx;
type ReceiptEnvelope = N::ReceiptEnvelope;
type Header = N::Header;

type TransactionRequest = TransactionRequestWithContext;
type TransactionResponse = N::TransactionResponse;
type ReceiptResponse = N::ReceiptResponse;
type HeaderResponse = N::HeaderResponse;
type BlockResponse = N::BlockResponse;
}

// ... rest implementations for NetworkWithContext (like reccomended-fillers) & for TransactionRequestWithContext
```

However obvoiusly it doesnt work,so I had to wrap `N::TransactionResponse;` `N::UnsignedTx` to implement From and other traits specified by Network trait (Wrappers needed because of orphan-rule). This lead me to rabbit hole of wrapping almost everything only to be defeated by `BlockResponse` :D - one of its methods return reference to struct containing Vec of type T which I would need to transmute into Vec of type U - which I could using unsafe transmute but here I decided to stop :D.

My workaround:
Implement the wrapper per concrete network types (e.g., Ethereum) and only make the TransactionRequest a wrapper. This works but I need to do it for all networks.

What I'm trying to achieve:

My main use case is retry-aware gas scaling. I want to pass an attempt counter with the transaction so a custom filler can bump fees more aggressively on retries — but still use the default GasFiller to get the base estimate. Right now I'd have to break out of the filler pipeline and manually orchestrate steps, which works, but is kinda messy. I have also other steps that I can do without fillers with context but all of them are much nicer after being converted into Fillers.

More generally, it would be nice if fillers could access transaction-specific metadata without having to maintain external state and correlate by hash or nonce.

### Additional context

I'm aware this is potentially a large change and might not even be compatible with the philosophy of the codebase. At leaast I wanted to share my use case and the walls I hit trying to solve it generically.