Reduce false positives for @hsh{$s} and @ary[$s] warnings

Reduce false positives for @hsh{$s} and @ary[$s] warnings

This resolves tickets #28380 and #114024.

Commit 95a31aad5 did something similar to this for the new %hash{...}
syntax.  This commit extends it to @ slices and combines the two
code paths.

The heuristics in toke.c can easily produce false positives.  So the
op is flagged as being a candidate for the warning.  Then when op.c
has the op tree available, it examines it to see whether the heuristic
may have been a false positive.

This avoids bugs with qw "foo bar baz" and sub calls triggering
the warning.

The source code is no longer available for the warning, so we recon-
struct it from the op tree, skipping the subscript if it is anything
other than a const op.

This means that @hash{$foo} comes out as @hash{...} and @hash{foo} as
@hash{"foo"}.  It also meeans that @hash{"]"} is displayed correctly
instead of as @hash{"].

Commit 95a31aad5 also modified the heuristic for %hash{...} to exempt
qw altogether.  But it did not exempt it if it was preceded by a tab.
So this commit rectifies that.

This commit also improves the false positive detection by exempting
any ops returning lists that can get past toke.c’s heuristic.  I went
through the entire list of ops, but I may have missed some.

Also, @ slices on the lhs of = are exempt, as they change the context
and are hence actually useful.