docs: update bounded description

[MingweiSamuel]

@shadaj

the semantics of Bounded require that the data is synchronously available in the same tick (rather than appearing in future ticks which is what resolve_futures does).

HOWEVER, we recently added resolve_futures_blocking which is exactly the solution for this I believe! It freezes the tick until the futures resolve, which would allow preserving boundedness (in fact, it would also allow us to offer this API inside a tick). Currently we only have an implementation for unordered in DFIR but should be easy to add a resolve_futures_blocking_ordered operator as well.

But we should be careful documenting this. In most cases developers don't actually want to block (they can stream-ily process the results as they materialize), so we should make it clear when to use what.

I see. That distinction could probably be clearer in this documentation.

Originally posted by @akainth015 in #2601 (comment)

[akainth015]

There should probably be a unit test that fails when the behavior is changed as it was in my PR

[shadaj]

We definitely can have a regression test, use something like clone_into_tick which won't work correctly unless the bounded semantics are correctly tested. I'm not sure if we can have a broader test to prevent accidental Bounded, though, since the type is just a marker and requires the core library developers (us) to think carefully about the semantics.