Restrict functions which aren't allowed e.g. WHERE after LIMIT

[martijndeh]

Whatever you type in Mammoth gets translated to SQL 1 to 1 (more or less). The point is at least that this makes the order of functions important. For example, currently you may write select(foo.id).from(foo).limit(2).where(foo.value.eq(123)) which would output a query with a limit first and where later which is obviously incorrect.

Because we want to stick to SQL as close as possible, we don't want to sort the output tree to fix the query, instead, we want to give type hints to indicate something is not possible.

To achieve this, we can probably omit certain functions from the query if they can be considered invalid e.g. we cannot do a .where() anymore after a .limit() as that would be invalid SQL. This makes Mammoth a little bit more type safe and the autocomplete really nice :).

[lorefnon]

Because we want to stick to SQL as close as possible, we don't want to sort the output tree to fix the query, instead, we want to give type hints to indicate something is not possible.

I think it would be good if the consumer didn't have to think about the sequence and the query builder did the right thing always (resequence appropriately).

Also the default sequence supported by sql is neither great nor intuitive imho. Eg. I almost always want to start my query chain with from so that in select/where I can get better autocompletion (Eg. FunSQL for julia). I also always forget whether limit comes first or order and it would be nice if I didn't have to bother about it.

I am not sure how strongly you feel about aligning close to sql but I can take a stab at a PR if implicit resequencing is acceptable.