Describe the bug
sqlfmt error with jinja syntax for start and endcall blocks when they have parameters, like a normal macro function.

Similar to issues #335 and #338

To Reproduce
Run sql-fmt on the following code:

{% call(table) macro_name(list_of_tables) %}
select foo, bar from {{ table }}
{% endcall %}

The "table" parameter at the call block level breaks the parser.

Expected behavior
The call block should be parsed without errors, the same way the code is parsed correctly when the call block doesn't contain any extra arguments. For example:

{% call macro_name(list_of_tables) %}
select foo, bar from {{ table }}
{% endcall %}

Removing the call block parameter, the source code is parsed correctly, but the parsing fails when some arguments are included.

Actual behavior
The current behaviour raises an error when arguments are used in a call block:

sqlfmt, version 0.14.3
sqlfmt encountered an error: Closing bracket '{% endcall %}' found at 99 before bracket was opened.

Removing the (table) block argument, the formatting works as expected.

On the other hand, including a -- fmt: off clause does not avoid the error :(
The parser still fails when processing the file.

Additional context
The ability to pass back arguments to a jinja call block is supported in the jinja v2.x present in dbt: https://jinja.palletsprojects.com/en/2.11.x/templates/#call

It's a sort of advanced jinja functionality, but it would be great to be supported by sqlfmt. The tool should be able to parse a call block that has defined an extra set of parameters, similar to any other jinja macro.

Thank you very much!