update to i_overlay 1.9

Note there is a serious performance regression for larger geometries in our benchmarks vs. 1.8.

    cargo bench --bench=boolean_ops -- --baseline=main
    ... small ones are fine, but big ones have huge regression
    Circular polygon boolean-ops/bops::union/1024
                            time:   [4.3625 ms 4.3922 ms 4.4093 ms]
                            change: [+1.7493% +2.4971% +3.2026%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Circular polygon boolean-ops/bops::intersection/2048
                            time:   [14.057 ms 14.115 ms 14.157 ms]
                            change: [+9.0224% +10.438% +11.658%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Circular polygon boolean-ops/bops::union/2048
                            time:   [14.012 ms 14.071 ms 14.134 ms]
                            change: [+11.212% +12.141% +13.317%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Found 1 outliers among 10 measurements (10.00%)
      1 (10.00%) high severe
    Circular polygon boolean-ops/bops::intersection/4096
                            time:   [360.66 ms 361.18 ms 361.83 ms]
                            change: [+709.38% +713.12% +716.34%] (p = 0.00 < 0.05)
                            Performance has regressed.
    Found 2 outliers among 10 measurements (20.00%)
      2 (20.00%) high severe
    Circular polygon boolean-ops/bops::union/4096
                            time:   [361.35 ms 361.71 ms 362.13 ms]
                            change: [+710.58% +713.76% +716.59%] (p = 0.00 < 0.05)
                            Performance has regressed.

Likely this is because there is a new heuristic for "solver" strategies
based on how big your input is - the cliff likely indicates the switch
to one of the solvers used for larger inputs.

See iShape-Rust/iOverlay#13

There are significant gains with some "real world" data, e.g. urshrei's cascaded
union tests:
#1273 (comment)

I'm more inclined to trust that more realistic data over the synthetic
geometries we use in our benchmarks.

Plus, I'd prefer to leave in performance twiddling to upstream and
contribute changes there rather than fine-tuning things at our own
call sites.

geo/Cargo.toml

@@ -31,7 +31,7 @@ proj = { version = "0.27.0", optional = true }
 robust = "1.1.0"
 rstar = "0.12.0"
 serde = { version = "1.0", optional = true, features = ["derive"] }
-i_overlay = { version = "1.8.0, < 1.9.0", default-features = false }
+i_overlay = { version = "1.9.0, < 1.10.0", default-features = false }
 
 [dev-dependencies]
 approx = ">= 0.4.0, < 0.6.0"