Note [Strictness and Unboxing]

If an argument is used strictly by the function body, we may use use
call-by-value instead of call-by-need for that argument. What's more, we may
unbox an argument that is used strictly, discarding the box at the call site.
This can reduce allocations of the program drastically if the box really isn't
needed in the function body. Here's an example:
```
even :: Int -> Bool
even (I# 0) = True
even (I# 1) = False
even (I# n) = even (I# (n -# 2))
```
All three code paths of 'even' are (a) strict in the argument, and (b)
immediately discard the boxed 'Int'. Now if we have a call site like
`even (I# 42)`, then it would be terrible to allocate the 'I#' box for the
argument only to tear it apart immediately in the body of 'even'! Hence,
worker/wrapper will allocate a wrapper for 'even' that not only uses
call-by-value for the argument (e.g., `case I# 42 of b { $weven b }`), but also
*unboxes* the argument, resulting in
```
even :: Int -> Bool
even (I# n) = $weven n
$weven :: Int# -> Bool
$weven 0 = True
$weven 1 = False
$weven n = $weven (n -# 2)
```
And now the box in `even (I# 42)` will cancel away after inlining the wrapper.

As far as the permission to unbox is concerned, *evaluatedness* of the argument
is the important trait. Unboxing implies eager evaluation of an argument and
we don't want to change the termination properties of the function. One way
to ensure that is to unbox strict arguments only, but strictness is only a
sufficient condition for evaluatedness.
See Note [Unboxing evaluated arguments] in "GHC.Core.Opt.DmdAnal", where
we manage to unbox *strict fields* of unboxed arguments that the function is not
actually strict in, simply by realising that those fields have to be evaluated.