Fix rendering of custom tags with more than one parameter

[pmenhart]

Trying to add moderately complex custom tags, I encountered a problem:

• All tag parameters were concatenated into one string, e.g. {% mu for foo as bar %} was presented as one node ["forfooasbar"] in Tag method render(context, nodes)
• Caused by combining text of all children of token 'other_tag_parameters' in NodeVisitor.visitSimple_tag()
  Implementation was changed in Optimize the parsing of large templates #227. I reviewed the related tickets and didn't find justification for the concatenation
• This PR separates each parameter to a distinct node, i.e. ["for", "foo", "as", "bar"]

I am focused on the Liquid flavor, but the change should work well for Jekyll as well.
There was one Jekyll scenario with failing tests, revealing an unrelated problem with parsing of include_relative. I submitted #300 as a prerequisite of this PR.

@msangel I'd appreciate your insight. I'm wondering if there was a reason for such string concatenation in #227 I am not aware of?

For reference, the original pre-227 code:

public BlockNode visitOther_tag_block(Other_tag_blockContext ctx) {
    BlockNode node = new BlockNode(isRootBlock);
    for (AtomContext child : ctx.atom()) {
      node.add(visit(child));
    }
    return node;
  }

cc @bkiers

[msangel]

I don't know the answer.

I think it was made so for giving end-user to define own way of parsing parameters. Interesting related scenario: #196 (comment)

No clear reasoning for me why it was made so, as well as what is better. In the end, calling str.split('\\s') is not that hard.

Lets see what @bkiers will say on this.

[pmenhart]

True, parsing can be delegated to custom tag implementation. Unfortunately, whitespace is not preserved at the moment: for foo as bar is transformed into a single string "forfooasbar". We cannot detect original boundaries.

[msangel]

It’s true.

[bkiers]

I don't know the answer.

I think it was made so for giving end-user to define own way of parsing parameters. Interesting related scenario: #196 (comment)

No clear reasoning for me why it was made so, as well as what is better. In the end, calling str.split('\\s') is not that hard.

Lets see what @bkiers will say on this.

Me neither. @pmenhart's changes look sound en well tested! 👍

Thanks both!