Output values type annotations

[3bl3gamer]

This is the continuation of #52 which I had closed by mistake. The bugs which I've highlighted then seems already fixed, so this PR is only about types now.

Added JSDoc type annotations for output values

I've added type annotation for class properties and some function arguments so return types of exported functions (like parseARule()) can now be inferred.

This may be very useful, for example, in this code:

const comp = parseAComponentValue('...')
if (comp.type === "FUNCTION") {
	console.log(comp.name, comp.value.length)
}

a editor with enabled TypeScript features (such as VSCode) will suggest that comp has a type property with one of predefined values ("BLOCK", "IDENT", "FUNCTION", ...) and inside if condition the comp type will be narrowed down to Func with string name and array value.

For simplicity, arguments of exported functions and some of the internal code is not type annotated.

while(1) loops are now while(true) because "1" is not an "endless" condition for TS

This function return type will be number | undefined, but with while(true) the type will be number as expected:

function f() {
  while(1) {
    return 0
  }
}

I've used this jsconfig.json (not included to PR)

{
  "compilerOptions": {
    "checkJs": true,
    "noEmit": true,
    "strict": true,
    "noImplicitAny": false,
    "lib": ["ES2015", "DOM"]
  },
  "include": ["parse-css.js"]
}

Question about consume()

There are some loops with condition while(consume()) which looks as if consume() will eventually stop the loop by returning false. But it won't: it always returns true. Is it intended? Will consume() someday start returning false?

If it won't, maybe remove return true from consume() and rewrite loops conditions to

while(true) {
  consume()
  ...
}

to make it clear (for user and type checker) that consume() is not a condition?