Rudimentary code completion support

[nolanderc]

Uses glslang to get a string containing the GLSL definitions of all builtin functions and variables for the given shader stage. This is then feed through a very naive "parser" to extract the types and names of all global symbols.

I did not feel like writing a parser for GLSL, and the one embedded in glslang is buried deep within implementation details. Instead we use some simple heuristics to find all declarations in a file. For example, input variables and constants follow the same basic pattern:

[[<layout>] <qualifier>] <type> <name> [= <value>];

Thus, if we see either ; or =, whichever comes first, the previous two "words" must have been the name of the symbol and its type.

Using a similar approach we can identify functions: if we ever see a pair of parentheses outside a function body, we assume it is either a layout qualifier or parameter list.

Granted, this solution is not that fault-tolerant, but it works reasonably well. In the future we might want to use an actual parser, but that is more work than I wish to spend on this at the moment.

It should be noted that the current approach does not handle local variables or anything defined within a function body, which would depend on the editing context. Theoretically, this could be implemented by truncating the file to the position of the cursor, and only considering symbols up to that point, but then you have to deal with all the various syntax forms allowed within statements and expressions, which I did not want to deal with (again, a proper parser would solve this).

Also, most editors have some way of automatically completing recently used words in the surrounding context, which already gets us 70% of the way (only missing type hints).

This includes the commit from #26, which I needed for testing, so consider merging that PR first.

The commit 4f84431 additionally fixes #19.

Edit: Here's a screenshot with code completion working:

To get this result, I typed mul and then selected the first option. Notice that the type signature of the function is shown. The same is true of all builtin functions and constants.

[svenstaro]

Probably should update the README accordingly.