Variants of clojure.core functions (and internal helpers)
that release the head of seqs earlier, enabling lower peak memory
usage in some cases.

For example, many higher-order functions in this namespace release strong
references to arguments before calling their function arguments.
Realizing the following example would be prone to failure with an OutOfMemoryError using
clojure.core/map because map retains a strong reference to takes-75-percent-of-heap
when calling its function argument, which prevents memory from being reclaimed to create
another value of that size.

(map (fn [takes-75-percent-of-heap]
       (if (< (rand) 0.5)
         takes-75-percent-of-heap
         (generate-another-value-taking-75-percent-of-heap)))
     [takes-75-percent-of-heap])

In contrast, using head-releasing/map, the garbage collector can reclaim takes-75-percent-of-heap
while calculating (generate-another-value-taking-75-percent-of-heap) because
head-releasing/map does not strongly reference takes-75-percent-of-heap at that point.

The basic implementation trick to achieving this is to call (rest s) on the seq currently
being processed _before_ calling (f (first f)), so the strong reference to (first f)
is transferred from the higher-order function to f during the call to f.

There are potential caveats to this approach: https://clojure.org/reference/lazy#_extension_iseqs
If the underlying ISeq implementation defines rest in terms of next as in the article, then the
functions in this namespace will force two seq elements into memory simultaneously.
For example, the call below will throw an OutOfMemoryError before the fn is called because both
elements of the seq will be realized.

(map (fn [takes-75-percent-of-heap] nil)
     (lazy-seq-where-rest-calls-next
       (cons (->takes-75-percent-of-heap)
             (lazy-seq [(->takes-75-percent-of-heap)]))))

Infinite lazy seqs such as cycle or repeat always hold strong references to all their elements, so
the functions in this namespace will have no affect in the memory usage of processing these seqs.

Another caveat is that the functions here are perhaps more useful as
validation of the leaky-seq-detection framework and for pedalogical purposes about sequences
than as significant bump in real-world expressivity.
See the tests for how these implementations were verified:
  io.github.frenchy64.fully-satisfies.leaky-seq-detection-test

The author of this namespace can only speculate why the original functions were written this way.
Perhaps the idea of a fn releasing a strong reference to one of its arguments was too rare to risk
the caveats in using the default implementation of ISeq. Chunked seqs are also so prevalent
and have much higher memory requirements that the optimizations in this namespace might
have been deemed insignificant. For example, map processing a chunk of 32 must have enough memory
to hold both 32 elements of the input collection and 32 elements of the output collection simultaneously.
Chunked seqs also make programs such as the above unidiomatic since they are so difficult to get right
(see the hoops math.combinatorics jumps through to reduce the 32+32 elements of the previous example to
32+1).

At the very least, this work helps crystallize the differences between rest and next---or
more precisely, their similarities: while rest does not realize the next element, nor tell us whether
a seq has more elements, it is still an eager operation whose result, like next, releases a strong
reference to the first element of the seq.