Address LineStringSegmentize bugs

[JosiahParry]

• [x] I agree to follow the project's code of conduct.

• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

Thanks to @Robinlovelace for doing tests on real data. Brought to light 2 categories of edge cases where the number of LineStrings in the resultant MultiLineString was not the same quantity as requested by the n parameter.

Bug occurred when:

• There were only 2 coordinates in the LineString and
• When the Line length was larger than the maximum size of a segment

This has been addressed through the use of the Densify trait.

LineStrings are densified to ensure that a Line segment never has to be partitioned more than once. Additionally, after densification the lines are counted. If the number of lines is exactly n, then the function is exited early.

An additional change was made which incorrectly would return the Line of a LineString if there were n lines. This was wrong because the length may have not been equivalent. I have removed this check and early return. I've removed a test that tested for this equivalence since it was a bad assumption.

I've also removed the unneeded peekable() call.

---

Aids downstream:

• https://github.com/JosiahParry/rsgeo/issues/28
• https://github.com/ropensci/stplanr/issues/546

[JosiahParry]

Thanks for your speedy help, @urschrei !!