* Strainer has a class cache that creates Strainer subclasses for each filter
set that is used on .create calls.
* Context now creates a list of filters and passes this to Strainer.create to
utilize the class cache in almost all use cases.
* If add_filter was called after a render, then the method cache may still be
invalidated.
Conflicts:
lib/liquid/strainer.rb
1.8.7 compatibility fix
In Ruby 1.8.7, Hash does not preserve insertion ordering as Array does.
This could cause a problem when registering filters which depend on others and
the registration order is important.
So, the @@filters variable was changed to array where the order of the filters is
the same as the insertion order.
After moving the method existence check from Context into Strainer,
updated Strainer to only accept invokation methods that were added via
filter Modules, and done in a way that respond_to? is never called,
preventing unconstrained Symbol table growth.
chenxianyu