fix: avoid scientific notation in CMR URL coordinate parameters

[stark256-spec]

Summary

Fixes #108

Python's default float-to-string conversion uses scientific notation for numbers outside roughly [1e-4, 1e16). For example, 0.00001 becomes "1e-05". CMR rejects scientific notation in URL parameters:

{"errors":["[42.0,1e-05] is not a valid URL encoded point"]}

This caused queries using coordinates near the equator (or any latitude/longitude/distance with small absolute value) to fail.

Fix

Added _format_float() which checks whether the default g-format string contains e/E and falls back to fixed-point formatting with trailing zeros stripped:

>>> _format_float(0.00001)
'0.00001'
>>> _format_float(42.5)
'42.5'
>>> _format_float(42.0)
'42'

Applied to all five coordinate methods: point(), circle(), polygon(), bounding_box(), line().

Test

from cmr import GranuleQuery
q = GranuleQuery().short_name("FOO").point(42, 0.00001)
assert "1e" not in q._build_url()
# 'https://cmr.earthdata.nasa.gov/search/granules.json?short_name=FOO&point[]=42.0,0.00001'

[chuckwondo]

Thanks @stark256-spec. The default branch is develop, not main, so please retarget your PR to develop, then I'll review.

[stark256-spec]

Done — retargeted to develop. Thanks for the catch!

[stark256-spec]

Closing this in favour of a clean replacement — the branch inadvertently included unrelated client_id() and multi-platform changes stacked from a previous branch, making it equivalent to the already-closed #111. Testing also revealed two bugs in the _format_float helper (integers were gaining spurious .0 suffixes, and whole floats were losing their decimal point). Both are fixed in the replacement. A new PR targeting develop contains only the scientific notation fix with all 122 existing tests passing.