Fix: standalone inverse tags ({{^helper args}}) drop params/hash arguments

[tomasbjerre]

Bug

visitUnless() in TemplateBuilder.java (which handles a standalone
inverse tag, {{^helper args}}...{{/helper}}) always constructs its
Block with Collections.emptyList()/Collections.emptyMap() for
params/hash, discarding whatever ctx.sexpr() actually parsed:

Block block =
    new Block(
        handlebars,
        name,
        true,
        "^",
        Collections.emptyList(),   // <- parsed params thrown away
        Collections.emptyMap(),    // <- parsed hash thrown away
        blockParams(ctx.blockParams()),
        source(ctx));

The sibling visitBlock(), which handles the positive form
({{#helper args}}...{{/helper}}) and shares the exact same sexpr
grammar rule (sexpr : QID param* hash*), correctly does:

params(sexpr.param()),
hash(sexpr.hash()),

So the grammar parses hash/param arguments on a standalone inverse tag
just fine (unless : UNLESS sexpr blockParams? END body END_BLOCK nameEnd=QID END) - the visitor just never wires them through for that
one code path.

Impact

For a helper that only checks truthiness of a plain value this is
invisible, since most such usages don't pass extra args. But a custom
helper that relies on its own hash argument, e.g.

{{^ifSomething . scope="x"}}...{{/ifSomething}}

silently gets options.hash("scope") == null instead of "x".
Depending on what the helper does with that, this can surface as a
confusing NullPointerException deep inside otherwise-correct helper
code, with no indication that the argument was dropped by the parser
rather than by the helper.

I ran into this in a Handlebars template that used
{{^ifCommitScope . scope="deps"}}...{{/ifCommitScope}} (a custom
helper mirroring the existing ifCommitScope positive-form pattern)
and got an NPE from inside Options.hash(String) that took a while to
trace back to this.

Fix

Mirror visitBlock() exactly: params(sexpr.param()) /
hash(sexpr.hash()) instead of the hardcoded empty collections.

Tests

Added UnlessBlockHelperArgsTest with two cases:

• the first positional param becomes the helper's context argument
  (matching how visitBlock()/the positive form behaves)
• an additional positional param and a hash argument are both
  available via options.param(0) / options.hash(...)

Ran the full handlebars module test suite locally:
1030 tests, 0 failures, 0 errors (3 pre-existing skips, unrelated).

No other files are touched; I intentionally left the spotless:apply
formatting drift on unrelated pre-existing files (Handlebars.java,
StringHelpers.java, Text.java, a few test files) out of this PR to
keep the diff scoped to the actual fix.

[edgar-espina-wpp]

thank you