Accept an option to return indexed vertices

[mourner]

Updates the API to have an option to return indexed vertices. Closes #4. Second attempt after #5.

Indexed result has a performance cost of ~10-20%. Here are some benchmarks:

# indexed
typical OSM building (15 vertices): x 480,756 ops/sec ±0.71% (98 runs sampled)
dude shape (94 vertices): x 24,276 ops/sec ±0.73% (99 runs sampled)
dude shape with holes (104 vertices): x 15,891 ops/sec ±0.85% (97 runs sampled)
complex OSM water (2523 vertices): x 331 ops/sec ±0.67% (91 runs sampled)

# non-indexed in indexed2 branch
typical OSM building (15 vertices): x 589,032 ops/sec ±0.75% (98 runs sampled)
dude shape (94 vertices): x 26,615 ops/sec ±0.71% (97 runs sampled)
dude shape with holes (104 vertices): x 16,945 ops/sec ±0.96% (98 runs sampled)
complex OSM water (2523 vertices): x 339 ops/sec ±0.78% (93 runs sampled)

# non-indexed in master branch
typical OSM building (15 vertices): x 608,334 ops/sec ±0.69% (99 runs sampled)
dude shape (94 vertices): x 26,400 ops/sec ±0.72% (97 runs sampled)
dude shape with holes (104 vertices): x 17,105 ops/sec ±0.74% (94 runs sampled)
complex OSM water (2523 vertices): x 344 ops/sec ±0.70% (95 runs sampled)

The configurability is worth it. Whether to use indexed output depends on the application, but we have it off by default.

This also breaks the 3D vertices use cases, we need to think about it API-wise.

cc @ansis @kkaefer