Implement error propagation expression: ?

[Kijewski]

This PR consists of three two a changes:

• Right now almost every expression needs to be parsed twice: expr_any() first parses the left-hand side of a range expression, and if no .. or ..= was found the left-hand expression is parsed again, this time as the result of the function. This diff removes the second parsing step by first looking for .. (opt rhs), then for lhs .. (opt rhs).
• Instead of having Expr::VarCall, Expr::PathCall and Expr::MethodCall, this diff unifies the handling of calls by removed the former three variants, and introducing Expr::Call. This makes parsing postfix operators easier.
• This change allows using the operator ? in askama expressions. It works like the same operator in Rust: if a Result is Ok, it is unwrapped. If it is an error, then the render() method fails with this error value.

[djc]

Haven't done an in-depth review of the final commit yet, but here's some feedback on the prerequisite refactoring steps.

[djc]

Having thought about this some more, I'm not sure I'm comfortable with the addition of the try operator. It seems like a bunch of complexity with a goal that I'm not sure meshes well with the design of Askama -- in my opinion, templates should generally be written not to yield errors. Did you have some concrete use cases where you wanted this behavior? I don't think fully matching the Rust grammar should be a goal unto itself.

(The changes to introduce a unified Call AST type seems nice, though.)

[Kijewski]

Right now the use of serde_json is expected at it's errors are caught in a nice way, but I guess serde_qs is equally as useful. Well, at least I am using serde_qs to generate URLs.

Right now I am formatting the query string outside of render(), and supply it in a field. But I would like it if I could use serde_qs::to_string() directly in the template without resorting to using unwrap().