When lambdas close over some external environment variable, if that
variable is a linear value, their environment becomes the owner of the
captured value and the value will be freed with the environment. If the
lambda moves this variable out of its own scope, however, e.g. by
returning it in its body, both the caller and the lambda environment
will wind up owning the value, resulting in double frees.

For now, we prevent this scenario by simply disallowing functions to
leak variables captured from another scope. Doing so is now an error. Of
course, one can still copy these values without issue.

We achieve this through set operations. If the memory state loses the
fake deleters for the set of a lambdas captured bindings after its body
is evaluated, we've encountered an ownership leak, and report an error.

```clojure
(defn example []
  (let [capture @""
        lambda (fn [] capture)])) ;; this is now an error

(defn example []
  (let [capture @""
        lambda (fn [] @&capture)])) ;; this is still OK
```

fixes carp-lang#1040

Adds tests to ensure lambdas do not leak ownership of their captured
variables. In addition, the nested lambda test now needs to accept a
reference to a function instead of a function value (otherwise an
ownership leak occurs).

At some point (I believe version 13.0.0?) clang added a warning that
catches variables that were assigned but unused. This version of clang
(or later) is now bundled w/ github's macos images and is causing our
tests to fail in continuous integration. We can currently generate C
code that trips this warning, so for now I've disabled it as we do some
other warnings related to variable usages.