Minor API Nits

[dlurton]

This issue can be thought of as late-arriving PR comments and is a low priority.

• ValueExpr variants are inconsistently named--some include the Expr suffix (i.e. ValueExpr::BinaryExpr), but others do not (i.e. ValueExpr::Path. This doesn't seem intentional--if it is, it would probably be a good idea to explain the naming convention in the rustdoc. Otherwise, I would propose to drop the Expr suffix on all the variants since it's redundant.
• ValueExpr variants sometimes contain all of their attributes and children directly in the tuple variant and other times other times they are contained within a struct that is the only element of the tuple variant. These probably should be consistently one or the other, or the convention should be included in the rustdoc.

pub enum ValueExpr {
   // attributes and children directly in the variant-tuple
    BinaryExpr(BinaryOp, Box<ValueExpr>, Box<ValueExpr>),
    // Why not BinaryExpr(BinaryExpr)?
    BetweenExpr(BetweenExpr),    
   // Why not: BetweenExpr(Box<ValueExpr>, Box<ValueExpr>, Box<ValueExpr>)?
   // note: this is just an example--there are several others with this inconsistency.
   // ...
}

• Some structs related to ValueExpr's variants, i.e. ListExpr, BagExpr, etc,
  have constructors while others do not, which makes me think the inconsistency was unintentional. Probably, they should all have constructors.
• partiql::Value::String for some reason contains a Box<String>. shouldn't that just be a String?
• Instead ValueExpr::List and ValueExpr::Bag, perhaps a single operator which includes an attribute that specifies if it should construct a bag, list or sexp? See also: Model bag, list, sexp better partiql-lang-kotlin#239
• The cases fields of SimpleCase and SearchedCase unnecessarily box their ValueExpr pairs. (The containing Vec is already a box of sorts.) At least, if there is a reason for this it's not immediately apparent.