WIP: Implement reference counting

[felixSchl]

Depends on #59

Introduce reference counting in order to avoid having to rely on a tracing GC.

Checklist, in order of priority:

• [x] Add memory leak tests for records and function on records
• [x] Make purs_cons_t reference counted and implement a free function on it
• [x] Add memory leak tests for purs_cons_t
• [x] Release modified records (record update syntax)
• [x] Heap-allocate the foreign member in the purs_any_t structure
  • [x] Make it reference counted
  • [x] Allow registering custom finalizers
• [x] Update code-gen to:
  • [x] Strings to use purs_str_new
  • [x] Scopes to use struct purs_scope
  • [x] Update purs_cons_t usage
  • [x] Update purs_foreign_t usage
  • [x] Release any non-returned *_new calls
  • [x] TCO
• [x] Check all call-sites of purs_any_unthunk - release intermediate results
• [ ] Warn (or, optionally, error) on mutual recursive bindings (due to retain cycle)
• [x] ~Allow for opt-in tracing GC (or drop support for tracing GC?)~ — out of scope for this PR
• [x] Explore making it easy to test compiled programs for leaks
• [x] Re-integrate upstream tests
• [x] Update to PureScript 0.13.x
• [ ] Improve releaseResources transform. The current implementation requires a ton of variables on the stack to ensure variables are not freed to early. Since dependencies between the variables is clearly visible, we should be able to re-use variables on the stack by releasing resources sooner (as soon as we know it's been retained by whatever ast node it was created for.) Clang/GCC compiler extension looks interesting: https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization#Clang_and_GCC_%22cleanup%22_extension_for_C
• [ ] ~Make AST transforms tail-recursive. This has been a problem prior to this PR, but is amplified by the large AST we produce.~ out of scope
• [ ] ~Implement #48. This PR currently heavily relies on statement expressions, which makes it easy to run into this clang error: fatal error: bracket nesting level exceeded maximum of 256~ out of scope, see -fbracket-depth=
• [x] Update previously ported libraries:
  • [x] :construction_worker_man: purescript-prelude
  • [x] :rotating_light: purescript-st
  • [x] purescript-record
  • [x] purescript-foldable-traversable
  • [x] purescript-arrays
  • [x] purescript-enums
  • [x] purescript-functions
  • [x] purescript-integers
  • [x] purescript-unfoldable
  • [x] purescript-assert
  • [x] purescript-effect
  • [x] purescript-math
  • [x] purescript-partial
  • [x] :rotating_light: purescript-lazy
  • [x] :rotating_light: purescript-refs
  • [x] purescript-control
  • [x] purescript-console

Icon	Meaning
:rotating_light:	Difficult / possibly impossible. Priority
:construction_worker_man:	In-progress

[felixSchl]

This was about as much time I could afford putting into this. It's pretty close and the TODO list above has been kept up-to-date. It would probably take another week or two to tow this across the line, not to mention updating libraries. If there's anyone who wants to take it up from here, I'd be happy to provide the necessary aid and assistance to familiarise you with the codebase and what needs to be done and so on. Otherwise expect slowing progress from here on out.

[felixSchl]

So I am updating the existing ported libraries for this PR and as was raised in #54 Control.Lazy does indeed cause a retain cycle and unreleased memory. I wonder what the best way to deal with this is. It seems the same problem also exists for non-TCO-ed recursive functions, e.g.:

go 10 = 10
go n = n + go (n + 1)

I wonder if we could drop in a tracing GC similar to what they do here https://github.com/brian-carroll/elm_c_wasm just for tracking these scenarios? This is the deep end of the pool for me though :)