Fix unwind passing

This fixes a whole class of "unwind passing" bugs, which are cases where the "unwind" values that are used to implement the effect of `break` / `continue`, `throw`, `exit` / `return`.

Some simple examples.

    ;; A function that simply "swallows" its argument:
    >> K: func [x] []

    >> foo: func [] [K return 42 return 99]
    >> foo
    == 99  ;; The `return 42` is "swallowed" by K. It shouldn't be.

Similar bugs are in REDUCE, WHILE, set-word! & set-path! handling, SET, APPLY, and AJOIN. A selection of a few more examples from the related CC tickets:

```
>> error? break
== true
; The unwind is passed to the ERROR? function instead of propagated.
; Should be ** Throw error: no loop to break

>> loop 1 [error? break/return "good" "buggy"]
== "buggy"  ; Should be "good"

>> reduce [return 42]
== [make error! 1]
```

Internally, the problem is that special-case handling for "unwind" values needs to be in place wherever values passing through the interpreter internals. Unwinds should never be assignable or be leaked back to the user level. This series of patches adds the required internal unwind handling.

This fixes CureCode issues [#1509](http://issue.cc/r3/1509), [#1515](http://issue.cc/r3/1515), [#1519](http://issue.cc/r3/1519), [#1760](http://issue.cc/r3/1760).