Binary size improvements related to #115

[fhackett]

See issue #115 for more discussion.

The key idea here is to use the SNMALLOC_SLOW_PATH macro, which is a cross-plaform noinline macro, on functions which construct, copy, and destroy long-lived pass, pattern, and WF objects.

These functions are only called on start-up, so they should have minimal performance impact. By default, they are inlined into Trieste pass defs and such. Some of their contents is rather bulky, like red-black tree copy routines, big reference count updates (including dynamic checks for whether glibc is multi- or single- threaded), and array resizing code.

Making these lifecycle functions explicit using = default and marking them with SNMALLOC_SLOW_PATH, alongside some other operators that might possible cause similar problems, saves 15-27% on code size for executables using Trieste.

[davidchisnall]

It would probably be nice to define a TRIESTE_SLOW_PATH macro, rather than import the snmalloc one (even if it's just #define TRIESTE_SLOW_PATH SNMALLOC_SLOW_PATH)

[fhackett]

@davidchisnall I saw a lot of SNMALLOC_SLOW_PATH and SNMALLOC_FAST_PATH in the codebase already, so the second commit adding that would be somewhat bigger.

That said, I would be fine doing that. It's just a search-replace.

[fhackett]

@mjp41 all done I think