Encode: make floats always contain a decimal point

[zostay]

Issue: #571

This is a fix to the integer to float conversion mentioned in #571.

This is breaking a test that seems to be ensuring that the existing behavior is preserved, so it's not ready for a merge. I didn't really know what to make of what this was testing, so if you'll let me know what this test is supposed to accomplish or how to correct it I will.

--- FAIL: TestUnmarshalCheckConversionFloatInt (0.00s)
    --- FAIL: TestUnmarshalCheckConversionFloatInt/float (0.00s)
        unmarshal_imported_test.go:1078: 
                Error Trace:    unmarshal_imported_test.go:1078
                Error:          An error is expected but got nil.
                Test:           TestUnmarshalCheckConversionFloatInt/float
FAIL
FAIL    github.com/pelletier/go-toml/v2/internal/imported_tests 0.308s

Also, I looked into adding support for unmarshalling into complex64 and complex128, but since you can't marshal those, that seemed a bit pointless. As far as I can tell, this is the only integer conversion missing. I suspect the reverse conversion is not a problem, but I did not look into it.

[pelletier]

Thanks for your interest in go-toml! I think the problem here is not to accept int to float as that could cause trouble (both v1 and BurntSushi's don't do that), but rather when using a float that can be represented as an integer, the marshaler emits what looks like an integer, and therefore the decoder the interprets it as an integer. The goal should be that a given struct can take a round trip (marshal then unmarshal that output).

[zostay]

Ah, I misunderstood the problem. Easy fix, though.

[pelletier]

Sorry for the late reply! Merged, thank you for the patch!