Some floats are printed like ints

I believe this is a very minor bug, but still a bug. Minor as it is, it also seems a good one for a first time user, so I'd like to give it a try.

Floats that could be coerced to ints are printed with no decimals, so the printed value looks like an int literal:

$ nix repl
Welcome to Nix version 2.2.2. Type :? for help.

nix-repl> builtins.typeOf (2 + 2.5)
"float"

nix-repl> builtins.typeOf (2 + 2.0)
"float"

nix-repl> 2 + 2.0
4

nix-repl> builtins.typeOf (2 + 2.0)
"float"

Here's the subsequent IRC channel talk, which explains rationale for dealing this issue:

12:53 < ivan> kandinski: I suspect this is a bug that could be fixed
12:54 < ivan> could be this in src/libexpr/eval.cc
12:54 < ivan>     case tFloat:
12:54 < ivan>         str << v.fpoint;
12:54 < kandinski> Yeah, I'm writing tutorial materials right now, that's how I came to it.
13:01 < __monty__> 4's a valid float literal though. I guess print then read isn't idempotent this way but there 
                   seems to be no coercion since typeOf correctly identifies it as a float?
13:02 < kandinski> yeah, it's just bad UX
13:02 < kandinski> in the sense that users can be confused of the type when they print it
13:09 < kandinski> I don't know a lot of C++, but it seems like it's C++ behaviour. NixFloat is a typedef'd double
13:10 < clever> kandinski: the problem would be the operator to apply << to whatever str is
13:10 < clever> with a double
13:10 < kandinski> clever, ah, so do you think << is overloaded there?
13:10 < kandinski> makes sense
13:10 < kandinski> everything else is standard C++ as far as I understand it
13:11 < clever> kandinski: the c++ stdlib should supply a << operator, for ostream and double, but does it do what 
                you expect?
          https://git.io/fjpnw
13:12 < kandinski> clever: right, so there are two questions. First one, what's the right behaviour? If the current 
                   one is deemed ok, then this is just a matter of documenting it and moving forward.
13:16 < kandinski> clever: Second question would be how to fix it if it's considered an issue that needs fixing.
13:17 < clever> kandinski: find your own function to convert a float to a string, then <<, that string
13:17 < __monty__> If there's a way to eval a string into nix then I'd prefer print then eval to be idempotent tbh.

I agree that idempotency of print/eval should be preferred, but the main reason is still reducing confusion to human users.