libserialize: Remove float preprocessing in serialize::json::Encoder

serialize::json::Encoder currently uses f64 to emit any integral type.
This is possibly due to the behavior of JavaScript, which uses f64 to
represent any numeric value.

This leads to a problem that only the integers in the range of [-2^53+1,
2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably
in the current implementation.

RFC 7159 suggests that good interoperability can be achieved if the
range is respected by implementations. However, it also says that
implementations are allowed to set the range of number accepted. And it
seems that the JSON encoders outside of the JavaScript world usually
make use of i64 values.

This commit removes the float preprocessing done in the emit_* methods.
It also increases performance, because transforming f64 into String
costs more than that of an integral type.

Fixes #18319

[breaking-change]
libserialize: Do not coerce to integer when decoding a float value

When an integral value is expected by the user but a fractional value is
found, the current implementation uses std::num::cast() to coerce to an
integer type, losing the fractional part. This behavior is not desirable
because the number loses precision without notice.

This commit makes it raise ExpectedError when such a situation arises.

[breaking-change]
libserialize: Always use a decimal point when emitting a float value

JSON doesn't distinguish between integer and float. They are just
numbers. Also, in the current implementation, a fractional number
without the fractional part is encoded without a decimal point.

Thereforce, when the value is decoded, it is first rendered as Json,
either I64 or U64. This reduces type safety, because while the original
intention was to cast the value to float, it can also be casted to
integer.

As a workaround of this problem, this commit makes the encoder always
emit a decimal point even if it is not necessary. If the fractional part
of a float number is zero, ".0" is padded to the end of the result.

[breaking-change]
libserialize: Code cleanup
libserialize: Prefer into_string() to to_string() wherever possible

Except for the example code!
Add ability to configure recursion limit.

Fixes #19318.
Kill dead code
Stop masking overflow and propagate it out more aggressively; also improve error reporting to suggest to user how to fix.
fix 404
work around portability issue on FreeBSD, in which the key returned from
pthread_key_create can be 0.
prefer "FIXME" to "TODO".
librustc: Fix debuginfo for captured variables in non-FnOnce unboxed closures.
Correct minor typos on the ownership guide.

liftimes -> lifetimes
Typo
Feature-gate explicit unboxed closure method calls & manual impls,
detect UFCS drop and allow UFCS methods to have explicit type parameters.

Work towards #18875.

Since code could previously call the methods & implement the traits
manually, this is a

[breaking-change]

Closes #19586. Closes #19375.
Fix false positive alerts from a run-pass test on Command.

Reported as a part of rust-lang/rust#19120

The logic of rust-lang/rust@74fb798a200dc82cf5b4a18065e3ea565229adc3 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.

Also, panic! inside a loop over all children makes the logic simpler.

By not destructing the return values of Command::spawn() until
find_zombies() finishes, I believe we can conduct a slightly stricter
test.

Signed-off-by: NODA, Kai <nodakai@gmail.com>
Implement lifetime elision for Foo(...) -> ... type sugar.

This means that `Fn(&A) -> (&B, &C)` is equivalent to `for<'a> Fn(&'a A)
-> (&'a B, &'a C)` similar to the lifetime elision of lower-case `fn` in
types and declarations.

Closes #18992.
Add a doctest for BTreeMap's iter method.
serialize: base64: allow LF in addition to CRLF and optimize slightly

It is useful to have configurable newlines in base64 as the standard
leaves that for the implementation to decide.  GNU `base64` apparently
uses LF, which meant in `uutils` we had to manually convert the CRLF to
LF.  This made the program very slow for large inputs.

[breaking-change]
serialize: base64: improve newline handling speed