New approach to function call matching

[nene]

Previously the approach to detecting function calls was as follows:

• Inside Tokenizer: save preceding whitespace of each token to whitespaceBefore field
• Inside Parser: check if RESERVED_KEYWORD or IDENTIFIER is followed by ( and there's no whitespace between them.

This has been a great hack to format function calls without really having a knowledge of which words are function names. But this approach has the fundamental downside of it relying on the whitespace of original code to make formatting decisions, which leads to surprising behavior (see #140 and #243) where re-formatting an already formatted SQL produces a different result.

The new approach introduced in this PR goes as follows:

• Inside Tokenizer: label all function names as type: RESERVED_FUNCTION_NAME tokens.
• Inside Parser: check if RESERVED_FUNCTION_NAME is followed by (.

This is mostly how one would expect this to work. However there are various caveats:

• A common convention is to format data types similarly to function calls e.g. DECIMAL(5, 2). For now this is solved by also including data types (that can take parameters) also to the functions list. In the future should completely separate data types from functions.
• CAST is used in various forms, but as its main use is in CAST(expr AS type), it's for now listed alongside functions.
• ANY and SOME can be used as aggregate functions, in which case they should be formatted as HAVING ANY(condition). But a way more common usage is as an operator: WHERE x = ANY (1, 2, 3). So I've opted to remove these from list of functions.
• NULLIF and COALESCE have sometimes been listed as keywords, at other times as function names. Changed them to be function names in every dialect. That really hints of a general problem that these keyword/function-name lists need a proper review.

The major downside of this new approach is, that:

• calls of a custom function like foo(1, 2) are now formatted as foo (1, 2).

But there's also a major benefit from parsing side:

• this change should greatly simplify switching to a parser-generator, as the parser won't have to look at whitespace (e.g. Nearley or Jison can't really distinguish between a token with and without preceding whitespace. Unless we go and introduce separate whitespace tokens, it's a major blocker for adopting a parser generator).

So, in the end it's about tradeoffs. IMHO the sacrifices are worth the gains.

[nene]

Here and in several other tests I've switched over to using the some widely adopted function names, so the tests would work across all dialects.

[nene]

Switched from IF to COALESCE which is supported in all dialects.

[inferrinizzard]

interesting that IF isn't as universal as COALESCE

[nene]

Not really sure which way is better here. It's not a function call.

However it should be possible to improve this with special parsing of WITH clause in the future.

[nene]

This is currently an unfortunate change in formatting.

This whole typed arrays/structs parsing needs a complete rewrite though. The current solution is a big hack. It should really be parsed inside Parser not hacked together inside postProcess() of tokenizer.

[nene]

Found lots of SQLite functions that we were missing.

[nene]

This change also paves the way for implementing separate uppercasing option for function names: #237

[inferrinizzard]

I think this overall makes sense but agree that the keyword lists need to be reviewed 👍