Separate core language tests for re-use in other liquid implementations

Ideally, we would have tests for the liquid language that could be shared for re-use across liquid implementations. This would better support re-implementations of liquid for performance reasons (e.g. liquid-c) or for making it usable from a different language.

These tests could be written in YAML without language specific extensions. The tests could then be run in ruby using meta-programming to define unit test methods for each YAML test. A ruby gem (from within this repo) could be provided for reimplementations of liquid with ruby bindings, which would just require an adapter for the implementations liquid API. Porting liquid for use from another language could just re-use the YAML and require some additional code to run/generate tests for each YAML test. Either way, this would allow for greater compatibility between implementations and simplify experimentation.

As a transitionary step, tests that can be decoupled from this library's API should use test helpers like assert_template_result & assert_match_syntax_error that abstract from the library API, as https://github.com/Shopify/liquid/pull/1611 started to do.

Tests for liquid extensions (e.g. custom drops, tags or filters) would depend on the library API and should probably be distinguished from language tests so they don't get converted to YAML tests. Perhaps they shouldn't use those decoupled test helpers like assert_template_result or assert_match_syntax_error to make it easier to separate those tests when we are ready to rewrite them in YAML.

Each YAML test would provide the liquid source, expected output and parameters for a single render. As such, we would need to separate ruby test methods that perform multiple renders into their own named test.

Start by reading the transitionary guidance in this issue and Shopify/liquid#1611, focusing on the assert_template_result and assert_match_syntax_error helpers. Identify which existing tests can be separated from library-specific extensions and represented as single-render YAML cases; done would mean a scoped, agreed test split and reusable test format.