The profiling runcore allows users and HLL developers to profile their programs at the PIR level.  Rakudo needs this desperately.

 * Make runloops pluggable (pluggable_runcore branch)
     * factor out the common runcore operations
     * define a struct to represent these operations
     * refactor existing runcores to use this struct
     * define a mechanism to load and register a new runcore
     * beware of runcore switching; probably need a better way to switch than compile-time constants
 * Create a new profiling dyncore
     * figure out the extra data and this runcore needs for profiling
         * open output file
         * store profiling information
         * close output file
 * Explore callgrind output format - see [wiki:CallgrindFormat] (NYTProf format a good second strategy)
     * How do you represent non-local jumps?
     * How do you detect non-local jumps and other CPS-style control flow changes?
     * How do you get current line number and source file from the active Context?
     * (stretch goal) How do you retrieve and record current HLL location?
     * How do you report different runcores (exceptions) and threads (interpreters)
     * Probably need to avoid PIO to avoid that overhead
     * Can you add timing to include what's expensive in C terms?

possible problem: can callgrind represent all the ways PIR can do control flow
 - parrot_op_info table gets populated based on what kind of flow
 - function attrs in ops files will probably help too

- if callgrind supports it, find what happens between ops (i.e. how much time between starting ops)