Introduce strictness levels to support incrementally adding strictness

Problem

Liquid has a strict parsing mode, which we can't simply make more strict without breaking existing liquid code that uses that strict parse mode.

Proposal

Instead of thinking of strictness checking as a boolean option, I think we should add the concept of strictness levels. This way we can introduce new strictness checks at a higher strictness level that won't break code that requires existing lower strictness levels.

Similarly, I don't think we should think of a :strict mode as being mutually exclusive with a :warn mode. Instead, we will want to both have errors for a required strictness level and as well as supporting warnings for a higher strictness level. This way the current strictness of the liquid code to be maintained while exposing warnings for a following strictness level, which can progressively fixed to allow the strictness level to be increased.

This strictness should be used for any errors that can be checked for statically, which are the type of checks we should prefer. For instance, I would like to replace the strict_filters option with a parse time check for use of undefined filters, which just requires providing the set of available filters as a parse option.

Future Considerations

Render-time checks will remain separate from these parse-time checks, since the process for detecting and fixing them can be quite different, but we still may want to consider exposing strictness levels, which could be useful for template development or for static site generators like jekyll.

Start by tracing Liquid's existing strict parsing mode and the strict_filters option to identify where parse-time checks are configured. Compare those paths with the separate render-time checks and consider how the proposed levels, errors, warnings, and available-filter parse option should interact; done is a reviewed design and implementation that preserves existing strict behavior while enabling incremental checks.