Refactor `ast_from_expression` to use clear stages of lexing and parsing

[Charles-Johnson]

Current implementation:

pub fn ast_from_expression(
    &mut self,
    s: &str,
) -> ZiaResult<SharedSyntax<C>> {
    let tokens: Vec<String> = parse_line(s)?;
    self.ast_from_tokens(&tokens)
}

SharedSyntax<C> currently aliases to a full binary tree with optional string representations and optional concept IDs at each node. This is quite messy because it keeps the original representation of the expression as well as sometimes associating a concept. This could be just replaced with concept ID if IDs of new compositions can be stored in the cache. The method name should be concept_from_expression in that case. Perhaps the ConceptKind should also be returned.

Instead of the above method being recursive, via ast_from_tokens, the method can implemented as 3 stages:

• calling the lex method
• transforming the lexemes into a concept tree by dropping the whitespace and branching based on parentheses
• determine the associativity and relative precedence of concepts to turn the tree into a full binary tree where each node is assigned a concept and the root concept ID is returned.

This should require a lot of code changes but should clean up a lot of code and separate concerns.

[Charles-Johnson]

In the dedicated stage to determine associativity and precedence I could avoid having to have "default" values for assoc _x_ and prec _x_. Instead the associativity and precendence could be set after this stage such that it is consistent with future parsing. Every new concept parsed should have it's associativity set to right unless the expression is actually setting the associativity to left. Likewise, every new concept parsed should have it's precendence set to default unless the expression sets the precedence to something else otherwise.

This will enable changing the associativity or precedence of a concept later with the new forget concrete concept whilst being able to check for contradictions in let expressions.