WIP: add get_current_relay_block function args to one path back toward relay chain

The parachain validation logic trends heavily toward functions, not
structs with methods. This is probably a good thing for efficiency,
but does make it harder to incorporate an external piece of state like
the current relay chain block number: we have to change several
functions signatures and their call sites, not just add a field
to a struct.

This commit partially traces back one of the chains of compilation
errors resulting from missing function parameters, adding parameters
to parent functions appropriately. At
`validation::collation::collation_fetch`, the parameters change from
type `BlockNumber` to type `F: Fn() -> BlockNumber`, because that loop
looks like a place where the relay chain might potentially change
during execution.

Unfortunately, this doesn't work as-is right now, because within
`validation::validation_service::launch_work`, we get errors that
`get_current_relay_block` may not live long enough. The compiler
suggests requiring a `'static` lifetime, which feels like a
strategy which won't work unless the struct where the relay chain
block number is actually stored is also `'static`. Adding a `'a`
lifetime tied to `&'a self` doesn't work either. It looks like the
restriction comes from `futures::task::Spawn`, whose future must
apparently conform to `'static`.

We could just pass the current block number all the way from the
top of the function chain, but it's not yet obvious how these functions
are called by the relay chain, and at what points the current block
might change during execution.

Therefore, questions:

- Can we assume that the relay chain current block will not change
  during execution of this function chain? If yes, we can just
  pass the block number, which is `Copy` and therefore in `'static`.
- If no, is there a reasonable way to get a `'static` function from
  the relay chain so we can still use this strategy to get the
  current relay block number?
- If no, how should we propagate this data? Channels maybe?
- If we retain the closure strategy, is it a problem to call the
  non-async function `get_current_relay_block` within
  `async fn collation_fetch`? Given that async closures are not
  yet stable, do we have the option not to?