javascript: Properly handle nested unknown blocks

Properly match open curly braces when parsing a statement not to
possibly get fooled by unexpected nested blocks, e.g. after a
`switch`'s `case` or a label.

This mostly reverts 5f6462e164987cd6d7226e1b6f79edcf82811511 and
replaces it with a more correct and complete solution.
javascript: Fix handling some class-related unterminated statements
javascript: Cleanup `findCmdTerm()` callers a bit

Move the check for unterminated inside `findCmdTerm()` itself and
return it rather than having each caller do it itself.
javascript: Fix scope inside nested blocks (if/else/while/for/etc.)
javascript: Fix more handling of class-related unterminated statements
javascript: Report function signature
javascript: Add some shebang aliases

* NodeJS: https://nodejs.org/
* Seed: https://wiki.gnome.org/action/show/Projects/Seed
* Gjs: https://wiki.gnome.org/action/show/Projects/Gjs
javascript: Improve support for unterminated statements

Add support for implicit semicolons so many unterminated statements'
end are properly recognized.

The implementation doesn't follow the ECMAScript standard because doing
so requires to recognize precise grammar of all constructs, and the
parser doesn't currently work this way.  So instead it uses some
heuristics that should work most of the time and only consider implicit
semicolons where they would be explicitly relevant to avoid most false-
positives.  See the extensive comment in `readTokenFull()` for details.

In practice, this mostly fixes handling of files using unterminated
variable assignations like the following:

    var v1 = 0
    var v2 = 1
    // ...
    function f1() {
        // ...
    }

In such situations the parser used not to be able to really tell where
the variable assignation would end and would not recognize any
statement before the next semicolon or closing curly brace at the same
level.  In practice, it wouldn't have emitted any tag for this example,
not even `v1` as it generates tags when reaching the statement's end.
javascript: Use a better technique to check shebang recognition

Include the `language` field in the output rather than try and use
esoteric syntax in the hope it wouldn't generate appropriate tags
in case of a parser mismatch.
javascript: Add support for the `const` keyword

`const` is not yet part of the current ECMAScript standard but is
part of the ECMAScript 6 draft and is supported by popular engines
including Mozilla and WebKit, and people already use it.

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const
javascript: Add support for the `let` keyword

`let` is not yet part of the current ECMAScript standard but is part of
the ECMAScript 6 draft and is supported by Mozilla, and people already
use it in some contexts.

Also, the current ECMAScript standard marks `let` as a "considered
reserved word" (7.6.1.2), so it is already a reserved keyword in strict
mode.

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let
Revert "javascript: don't add property if it is a regexp."

A regex is not a valid JavaScript property name, so remove specific
code to handle it.  Although this was added to prevent trying and
generate an empty tag, the parser has plenty of paths leading to this,
all of which are a lot more common than invalid syntax.

Anyway, a fix for generating empty tags should be more generic and not
handle one single invalid case.

This reverts commit c906e24872308eb8d5a8a5f648685b6b469da396.

Also, fix the test cases not to use this invalid syntax for no good
reason, as they were only supposed to check for regex handling.