lexer: allow extglob wildcards as function names

[riacataquian]

the lexer assumes an extglob token if any of the wildcards expressions
(such as @, and +) are succeeded by a left parenthesis but that
proves to be an issue if the wildcard is used as a function name.

example input:

$ cat in.sh
@() {
  echo "$@";
}

bash and gosh comparison:

$ bash ./in.sh
hello
$ ./gosh in.sh
in.sh:5:1: "}" can only be used to close a block

given in.sh, gosh reports about a syntax error - this is because
a closing bracket is found while the lexer isn't assuming a function
block

fix the issue by assuming a function if one of the conditions below is
true:

• if the expression is found at the beginning of the statement or if its
  preceded by a "function"
• if ( is immediately succeeded by a ) - although this is a valid
  bash syntax, we'll operate on the likelihood that it is a function

fixes #739

[mvdan]

I think a more reliable condition would be:

when I see @, if I peek the next two bytes to be exactly (), don't tokenize as a glob.

The slight wrinkle there is that, currently, we only have peekByte which only looks one byte ahead. However, looking two bytes ahead is still reasonable - we only need to be worried about peeking a large or unbounded amount of bytes. So, mimicking peekByte, you can imagine a peekBytes call - taking a string, ensuring that the buffer has enough bytes for it via fill, and then comparing with e.g. bytes.HasPrefix.

[riacataquian]

Thanks for the helpful inputs @mvdan, I added peekBytes and it seems a lot cleaner now. I didn't put any restrictions to the length of the string in question/for comparison, thought I'd leave that to the discretion of the caller.