A variety of GC fixes
Add per-thread caches to the allocator

Now, threads will claim an entire block at a time, and
put it in a thread-local cache.  In the common case, they
can allocate out of this block, and only need to take out
a lock if they run out.
The repl prints the repr(), not the str()
insert full blocks back at the end of the free list to hopefully reduce the amount of times we have to check them
Turns out a large amount of thread contention was coming from these shared counters -- disable some of them and add some thread-local caching
Enable vtune support and try to improve cache locality

Enable the VTune JIT support in llvm, and add it as a jit
listener.

I think it's mostly confirming my suspicion that the slowdown is
cache-related... it's not being very helpful with determining why
(it's in some function that it can't analyze).

I updated the memory allocator to have strong thread-affinity
(ie a thread now generally gets back memory that it had previously freed),
but that doesn't seem to have any effect.

Going to punt on further investigations for now, pretty happy though that there's
an overall speedup with the grwl, even if there are still issues.
I am really not good at running 'make format' before committing...
Ok fine, a vector of std::atomic is not safe.
merge