Type/Signature: changed confusing variable name

The variable `$closure` seems a bit prone to creating confusion here;
while the variable itself _is_ participating in a closure, closing
over the returned anonymous sub, we usually use "a closure" in the
nounal form to refer to a function enclosing something or ocassionally
to refer to a variable whose use is integral and obvious to the
purpose of the entire closure (as, say an iteration cursor).

In this case, it's simply a `C` value (where `C` is a type that can
participate as both arguments to `infix:</>`) that the closure sub is
remembering for later. So let's change its name to `$division`, since
that's more functional to the purpose. (I'd be fine with an extremely
formal name like `$C-result`, too, but the current `$closure` seems
neither fish nor fowl.)

---

p.s. Technically, we might be using a type where the result of an
`infix:</>` operation may not be correctly be referred to as "a
division", but it seems clearer than "closure" nonetheless. The
existence of an `(Any, Any --> Numeric:D)` multi seems to make this a
safe assumption, if not a guarantee.

If it _were_ guaranteed to always represent division, C<$quotient>
would be better, perhaps, but C<$division> seems to offer a reasonable
compromise to get the point across.

Author: treyharris

doc/Type/Signature.pod6

@@ -724,9 +724,9 @@ the function body.
     sub f(::T $p1, T $p2, ::C){
         # $p1 and $p2 are of the same type T, that we don't know yet
         # C will hold a type we derive from a type object or value
-        my C $closure = $p1 / $p2;
+        my C $division = $p1 / $p2;
         return sub (T $p1) {
-            $closure * $p1;
+            $division * $p1;
         }
     }