Support returning custom header on the client side as well

[bkchr]

#825 brought support for returning a custom header as part of the validation phase on the relay chain. This can be used for example to switch to a different chain. The problem now is that we also send the expected header as part of the candidate descriptor when building the collation: https://github.com/paritytech/cumulus/blob/master/client/collator/src/lib.rs#L178
The relay chain checks that the candidate descriptor header matches the one being returned by the validation function. This means we now also need to ensure that if a custom header should be set, we also use this header when announcing the collation to the relay chain validators. This should be done in the following way:

1. Bump the version of the CollationInfo runtime api to 2.
2. Change the collect_collation_info to also take the header of the current block and change the return value to also return the head data.
3. In the runtime we then check if a custom header should be set and if that is true, we return this custom header or we return the header that we got passed in through the runtime api function.
4. Ensure that the code on the client side is backwards compatible. This can be done by checking the current runtime api version and calling the appropriate "old" function.

CC @NachoPal