Note [Attaching CBV Marks to ids]

See Note [CBV Function Ids] for the *why*.
Before tidy, we turn all worker functions into worker like ids.
This way we can later tell if we can assume the existence of a wrapper. This also applies to
specialized versions of functions generated by SpecConstr for which we, in a sense,
consider the unspecialized version to be the wrapper.
During tidy we take the demands on the arguments for these ids and compute
CBV (call-by-value) semantics for each individual argument.
The marks themselves then are put onto the function id itself.
This means the code generator can get the full calling convention by only looking at the function
itself without having to inspect the RHS.

The actual logic is in computeCbvInfo and takes:
* The function id
* The functions rhs
And gives us back the function annotated with the marks.
We call it in:
* tidyTopPair for top level bindings
* tidyBind for local bindings.

Not that we *have* to look at the untidied rhs.
During tidying some knot-tying occurs which can blow up
if we look at the post-tidy types of the arguments here.
However we only care if the types are unlifted and that doesn't change during tidy.
so we can just look at the untidied types.

If the id is boot-exported we don't use a cbv calling convention via marks,
as the boot file won't contain them. Which means code calling boot-exported
ids might expect these ids to have a vanilla calling convention even if we
determine a different one here.
To be able to avoid this we pass a set of boot exported ids for this module around.
For non top level ids we can skip this. Local ids are never boot-exported
as boot files don't have unfoldings. So there this isn't a concern.
See also Note [CBV Function Ids]