The content_for tag should be supported by the parser and parse its arguments.

[charlespwd]

Describe the bug
Right now any kind of {% content_for 'block', id: something, name: something %} parses the markup as a flat string. It should be something easier to manage in checks/complete/etc instead.

https://shopify.dev/docs/api/liquid/tags#content_for

Source

{% content_for 'block', type: "", id: "" %}

Expected behaviour

const ast: LiquidHtmlNode = toLiquidHtmlAST(`{% content_for 'block', type: "", id: "" %}`);
const tag = ast.children[0];
assert(tag.name === 'content_for');
assert(tag.markup.type === 'ContentForMarkup');
// something like that
assert(tag.markup.contentForType  === 'block');
assert(tag.markup.kwargs.type === '...');

Actual behaviour

const ast: LiquidHtmlNode = toLiquidHtmlAST(`{% content_for 'block', type: "", id: "" %}`);
const tag = ast.children[0];
assert(tag.name === 'content_for');
// markup isn't a complex type, but a string! It means we need to do regex!
assert(typeof tag.markup === 'string');

Additional context

• I think we should "inspire ourselves" by how we parse the render tag
• this is how we describe the ConcreteLiquidTagRenderMarkup type
• this is where we map from the positional ohm arguments to the type
• this is where we define the RenderMarkup interface
• this is where we turn a ConcreteLiquidTagRenderMarkup into a RenderMarkup

At the end of the day, we should be able to do "richer" completion and theme checks when it comes to that tag once we parse it better.

[charlespwd]

e.g. stuff like this should be easier and safer to do!