Profiling the rendering of a liquid template

This is an improved version of what I originally put together in #361

This PR adds a simple profiling system to liquid rendering. Each liquid tag ({{ }} and {% %}) is processed through this profiling, keeping track of the partial name (in the case of {% include %}), line number, and the time it took to render the tag. In the case of {% include %} and any tag that requires blocks (like {% if %} and {% for %}), the tags inside of the partials and blocks are themselves marked as children in the final profiling structure, letting any user of this information view top level information and to dive down into more details. With this, it's now possible to track down exactly which tags are taking a long time to render.

Included in this PR are internal changes to parsing to calculate and keep track of the line numbers of individual tags and tokens in the source, as well as some specific tracking of the current partial, such that using the include tag will be tracked as a nested render. I initially looked into adding this information to error exceptions but that was proving more complicated and would require quite a few changes to how tags handle syntax errors.

I was able to hook profiling into Liquid through one small refactoring (`Block#render_token`) and alias method chain-like hooks into the appropriate classes, significantly reducing the code impact on the core Liquid code base. There are also changes to parsing to figure out the line numbers of the tokens, Template to start up a profiling pass, and to Tags and Variables for easier output of the contents of these items when printing out the profiled information, but otherwise the actual profiling is kept separate.  The hooks install and uninstall themselves as needed, which ensures that if profiling is turned off that there is no performance impact.

The current profiling runs for these changes can be found here: https://gist.github.com/jasonroelofs/79bde3d22ede168a5ae8

I've also put together an example template and resulting profiling output here: https://gist.github.com/jasonroelofs/c8148317ffb09e541633

If you prefer not to have this in the core I would love to discuss what changes Liquid does need for this functionality to live as its own gem and hooking into Liquid when needed.
I assume you do it like this to make sure you are thread safe? I don't think the way you install profiling hooks is thread safe (monkey patching the methods in one thread will also add them to the classes in all other threads. might even be racy.)