Geometry_Engine: strategy for geometrical tolerance

#### Description:

As discussed on the call, at the moment the attitude towards geometrical tolerance is rather relaxed. We have a multitude of cases, I gave myself 15 minutes for a search and found almost 10 of them.

**Correct:**
- methods that take `tolerance` argument and use for geometrical checks, e.g. `BH.Engine.Geometry.Query.Direction(Line)`
- methods that take `tolerance` argument, convert it to numerical tolerance and use for computation, e.g. `BH.Engine.Geometry.Compute.FitLine(IEnumerable)`
- methods that take `tolerance` argument, and do both of the above, e.g. `BH.Engine.Geometry.Compute.LineIntersections(Line, Line)`
- methods that take `tolerance` argument and pass it to other Geometry_Engine methods being called downstream, e.g. `BH.Engine.Geometry.Query.Centroid(Polyline)`

**Incorrect:**
- methods that take `tolerance` argument but do not pass it to other Geometry_Engine methods being called downstream and use default value instead, e.g. `BH.Engine.Geometry.Compute.CurveProximity(Polyline, Polyline)`
- methods that do not take `tolerance`, even though they should as they call other methods that use it e.g. `BH.Engine.Geometry.Query.Distance(Point, Arc)`
- methods that do take `tolerance` argument only for the reason of making the interface methods happy, but do not use it themselves
- methods that do take `tolerance` argument, but other methods of same name as well as correspondent interface methods do not, e.g. `BH.Engine.Geometry.Query.ClosestPoint` takes `tolerance` only for `Arc` and `Circle`

Probably a few more could be found. This looks messy, would be nice to standardize. My idea would be to make _every_ Geometry_Engine method accept `tolerance` argument with a default value. By these means we will make sure the code is consistent and we will lower the chance of tolerance not being passed downstream (easier to follow a single, clear standard + easier to CI check if every method call contains the argument).

What do you guys think?