Redis GEO commands should use the addReplyDouble API and not the addReplyDoubleDistance which is more expensive and lacks precision

Given we've optimized the addReplyDouble API in # and after doing a quick benchamrk as follows:

memtier_benchmark -c 10 -t 2 --pipeline 10 --test-time 60 --command "GEODIST key element1 element2" --hide-histogram

We can see that the majority of the CPU cycles within GEODIST are for snprintf. out the 30% cpu-cycles of GEODIST, 20% are for snprintf. Redis GEO commands should use the addReplyDouble API and not the addReplyDoubleDistance which is more expensive and lacks precision

Therefore I suggest we standardize the distance reply which will not only benefit approximate elements distance computation but also reduce the overhead of double to string conversion of the distance between points in the reply.