Cache parsed markup parts to avoid repeated calls during template render

Taking a second crack at #382. In the comments for that PR, @dylanahsmith mentioned that the variable lookup could be extracted during the parse phase and reused during the render phase. He explained it here: https://github.com/Shopify/liquid/pull/382#issuecomment-49326355.

I took a couple tries at separating parsing of variables and lookup/resolution. I kept getting tripped up by corner cases as well as my general lack of experience with the liquid codebase. I'm sure it's possible to achieve -- I just kept hitting cases which forced me to write some ugly looking constructs to get around.

So, in the interests of not letting perfect be the enemy of good, I went back to the original solution. I realized that the markup cache did not need to be a class based LRU but could just be a member of the Context class. That way, the variable would be parsed only the first time it was encountered. It must be resolved on each instance as it may be different for every execution (such as in loops).

Here's the current benchmark on my box for master (best of 3 runs):

```
                   user     system      total        real
parse:         2.040000   0.000000   2.040000 (  2.034119)
parse & run:   4.410000   0.000000   4.410000 (  4.421325)
```

And the object allocation profile:

```
==================================
  Mode: object(1)
  Samples: 8805500 (0.00% miss rate)
  GC: 0 (0.00%)
==================================
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
   1947200  (22.1%)     1462300  (16.6%)     Liquid::Context#variable
   2185900  (24.8%)     1433400  (16.3%)     Liquid::Variable#lax_parse
  10194700 (115.8%)      806100   (9.2%)     Liquid::Block#parse
    752500   (8.5%)      752500   (8.5%)     block in Liquid::Variable#lax_parse
   2944500  (33.4%)      521600   (5.9%)     Liquid::Block#create_variable
    438600   (5.0%)      438600   (5.0%)     Liquid::Template#tokenize
    480300   (5.5%)      433300   (4.9%)     Liquid::Context#find_variable
   2368300  (26.9%)      421100   (4.8%)     Liquid::Context#resolve
   3075100  (34.9%)      300600   (3.4%)     Liquid::Variable#render
   1075400  (12.2%)      295500   (3.4%)     block in Liquid::Variable#render
    289100   (3.3%)      289100   (3.3%)     Liquid::If#lax_parse
   2422900  (27.5%)      238800   (2.7%)     block in Liquid::Block#create_variable
    204800   (2.3%)      204800   (2.3%)     Liquid::StandardFilters#truncatewords
    146100   (1.7%)      143500   (1.6%)     Liquid::For#lax_parse
   9043900 (102.7%)      108700   (1.2%)     Liquid::Block#render_all
    600600   (6.8%)       98500   (1.1%)     Liquid::Context#invoke
     70700   (0.8%)       70700   (0.8%)     Liquid::Block#block_delimiter
     48300   (0.5%)       48000   (0.5%)     Liquid::Context#initialize
  10764400 (122.2%)       47600   (0.5%)     Liquid::Tag.parse
     47000   (0.5%)       47000   (0.5%)     block in Liquid::Context#find_variable
```

Now, here's the benchmark with the code in this PR applied (best of 3 runs):

```
                   user     system      total        real
parse:         2.040000   0.000000   2.040000 (  2.041081)
parse & run:   4.260000   0.000000   4.260000 (  4.269505)
```

And the object allocation profile:

```
==================================
  Mode: object(1)
  Samples: 8213900 (0.00% miss rate)
  GC: 0 (0.00%)
==================================
     TOTAL    (pct)     SAMPLES    (pct)     FRAME
   2185900  (26.6%)     1433400  (17.5%)     Liquid::Variable#lax_parse
   1349600  (16.4%)      864700  (10.5%)     Liquid::Context#variable
  10194700 (124.1%)      806100   (9.8%)     Liquid::Block#parse
    752500   (9.2%)      752500   (9.2%)     block in Liquid::Variable#lax_parse
   2944500  (35.8%)      521600   (6.4%)     Liquid::Block#create_variable
    438600   (5.3%)      438600   (5.3%)     Liquid::Template#tokenize
    480300   (5.8%)      433300   (5.3%)     Liquid::Context#find_variable
   1770700  (21.6%)      421100   (5.1%)     Liquid::Context#resolve
   2570800  (31.3%)      300600   (3.7%)     Liquid::Variable#render
   1056600  (12.9%)      295500   (3.6%)     block in Liquid::Variable#render
    289100   (3.5%)      289100   (3.5%)     Liquid::If#lax_parse
   2422900  (29.5%)      238800   (2.9%)     block in Liquid::Block#create_variable
    204800   (2.5%)      204800   (2.5%)     Liquid::StandardFilters#truncatewords
    146100   (1.8%)      143500   (1.7%)     Liquid::For#lax_parse
   7262000  (88.4%)      108700   (1.3%)     Liquid::Block#render_all
    600600   (7.3%)       98500   (1.2%)     Liquid::Context#invoke
     70700   (0.9%)       70700   (0.9%)     Liquid::Block#block_delimiter
     54300   (0.7%)       54000   (0.7%)     Liquid::Context#initialize
  10764400 (131.1%)       47600   (0.6%)     Liquid::Tag.parse
     47000   (0.6%)       47000   (0.6%)     block in Liquid::Context#find_variable
```

So, down 591,600 objects (6.72%) and better by ~150ms. And simple :-)

@camilo, @fw42, @dylanahsmith 
Since we know that we will always split the array into the first and second part, and this already creates a new array, could we just split the first and following parts in the variable cache? e.g. `@variable_cache[markup] = [parts.shift, parts]`

However, we could just start with what you have, and slowly extract more of the parsing step into this variable cache.  That probably means that we should move this out into its a private method (e.g. parse_variable).  This will make it easier to incrementally separate more of the variable parsing out of this method.