VehicleRestriction could absorb road class and turn restrictions

[nreinicke]

PR #204 introduced the concept of the VehicleRestriction.

@robfitzgerald points out that:

if you think about it, the mechanism for these restrictions is the same as the turn restrictions and road class restrictions. we could just absorb them here:

pub enum VehicleRestriction {
    MaximumTotalWeight((Weight, WeightUnit)),
    MaximumWeightPerAxle((Weight, WeightUnit)),
    MaximumLength((Distance, DistanceUnit)),
    MaximumWidth((Distance, DistanceUnit)),
    MaximumHeight((Distance, DistanceUnit)),
    MaximumTrailerLength((Distance, DistanceUnit)),
    RoadClass(u8),
    TurnRestriction(EdgeId, EdgeId)
}

then we generalize VehicleParameter to RestrictionParameter. A RoadClass restriction parameter is a RoadClass(HashSet(u8)) or whatever deserialized off the query. it would tidy things up since they all have the same logic

[robfitzgerald]

note: wrote this, then talked myself out of it, leaving it here for posterity.

had a thought about this. still thinking that the right path is an enum. wondering if there's a smart way to do this more generally, since we are proposing this work in the base repo. could we reduce the above into:

#[derive(Serialize, Deserialize)]
pub enum VehicleRestriction {
    EdgeWeightRestriction(???),
    EdgeDistanceRestriction(???),
    // ... other units
    NumericClassRestriction(u8),
    TrajectoryRestriction(Vec<EdgeId>)
}

downstream, a user could compose these as a CombinedFrontierModel.

thing is, that stuff in the ??? would need to be open enough in it's design to handle things like "expect a number on the query at the key axles, then multiply that by a key weight, and then do a <= operation."

eh, that's writing a whole nuther DSL, and it sounds awesome, but maybe that's future work to revisit later.