Had to make `struct Tm` in `libtime` not serializable for now.

By default, jemalloc is building itself with -g3 if the local compiler supports
it. It looks like this is generating a good deal of debug info that windows
isn't optimizing out (on the order of 18MB). Windows gcc/ld is also not
optimizing this data away, causing hello world to be 18MB in size.

There's no current real need for debugging jemalloc to a great extent, so this
commit manually passes -g1 to override -g3 which jemalloc is using. This is
confirmed to drop the size of executables on windows back to a more reasonable
size (2.0MB, as they were before).

Closes #14144

This was a more difficult change than I thought it would be, and it is unfortunately a breaking change rather than a drop-in replacement. Most of the rationale can be found in the third commit.

cc #13851

In an attempt to phase out the std::num::strconv module's string formatting
functionality, this commit reimplements some provided methods for formatting
integers on top of format!() instead of the custom (and slower) implementation
inside of num::strconv.

Primarily, this deprecates int_to_str_bytes_common

This is a migration of the std::{f32, f64}::to_str* functionality to the core
library. This removes the growable `Vec` used in favor of a large stack buffer.
The maximum base 10 exponent for f64 is 308, so a stack buffer of 512 bytes
should be sufficient to store all floats.

1. Wherever the `buf` field of a `Formatter` was used, the `Formatter` is used
   instead.
2. The usage of `write_fmt` is minimized as much as possible, the `write!` macro
   is preferred wherever possible.
3. Usage of `fmt::write` is minimized, favoring the `write!` macro instead.

These are reimplemented using the new `core::fmt` module.

Currently, the format_args!() macro takes as its first argument an expression
which is the callee of an ExprCall. This means that if format_args!() is used
with calling a method a closure must be used. Consider this code, however:

    format_args!(|args| { foo.writer.write_fmt(args) }, "{}", foo.field)

The closure borrows the entire `foo` structure, disallowing the later borrow of
`foo.field`. To preserve the semantics of the `write!` macro, it is also
impossible to borrow specifically the `writer` field of the `foo` structure
because it must be borrowed mutably, but the `foo` structure is not guaranteed
to be mutable itself.

This new macro is invoked like:

    format_args_method!(foo.writer, write_fmt, "{}", foo.field)

This macro will generate an ExprMethodCall which allows the borrow checker to
understand that `writer` and `field` should be borrowed separately.

This macro is not strictly necessary, with DST or possibly UFCS other
workarounds could be used. For now, though, it looks like this is required to
implement the `write!` macro.

This new method, write_fmt(), is the one way to write a formatted list of
arguments into a Writer stream. This has a special adaptor to preserve errors
which occur on the writer.

All macros will be updated to use this method explicitly.

These were temporarily moved to explicit implementations, but now that fmt is in
core it's possible to derive again.

This is used quite extensively by core::fmt

With std::fmt having migrated, the failure macro can be expressed in its full
glory.

Now that std::fmt is in libcore, it's possible to implement this as an inherit
method rather than through extension traits.

This commit also tweaks the failure interface of libcore to libstd to what it
should be, one method taking &fmt::Arguments

This commit moves all possible functionality from the standard library's string
formatting utilities into the core library. This is a breaking change, due to a
few tweaks in the semantics of formatting:

1. In order to break the dependency on the std::io module, a new trait,
   FormatWriter was introduced in core::fmt. This is the trait which is used
   (instead of Writer) to format data into a stream.
2. The new FormatWriter trait has one method, write(), which takes some bytes
   and can return an error, but the error contains very little information. The
   intent for this trait is for an adaptor writer to be used around the standard
   library's Writer trait.
3. The fmt::write{,ln,_unsafe} methods no longer take &mut io::Writer, but
   rather &mut FormatWriter. Since this trait is less common, all functions were
   removed except fmt::write, and it is not intended to be invoked directly.

The main API-breaking change here is that the fmt::Formatter structure will no
longer expose its `buf` field. All previous code writing directly to `f.buf`
using writer methods or the `write!` macro will now instead use `f` directly.

The Formatter object itself implements the `Writer` trait itself for
convenience, although it does not implement the `FormatWriter` trait. The
fallout of these changes will be in the following commits.

[breaking-change]

The Float trait in libstd is quite a large trait which has dependencies on cmath
(libm) and such, which libcore cannot satisfy. It also has many functions that
libcore can implement, however, as LLVM has intrinsics or they're just bit
twiddling.

This commit moves what it can of the Float trait from the standard library into
libcore to allow floats to be usable in the core library. The remaining
functions are now resident in a FloatMath trait in the standard library (in the
prelude now). Previous code which was generic over just the Float trait may now
need to be generic over the FloatMath trait.

[breaking-change]

Change `str::from_utf8_owned()` and `StrBuf::from_utf8()` to return `Result`.

This allows the vector to be recovered when it contains invalid UTF-8.

This used to be called `mangle` and was removed when the Robin Hood hash map came along, but it is a useful thing to have in certain situations (I just hit it with my Teepee header representation), so I want it back.

The method is renamed to `find_with_or_insert_with`, also with the parameters swapped to make sense—find and then insert, not insert and then find.

/cc @cgaebel

Let's try this again!

By default, jemalloc is building itself with -g3 if the local compiler supports
it. It looks like this is generating a good deal of debug info that windows
isn't optimizing out (on the order of 18MB). Windows gcc/ld is also not
optimizing this data away, causing hello world to be 18MB in size.

There's no current real need for debugging jemalloc to a great extent, so this
commit manually passes -g1 to override -g3 which jemalloc is using. This is
confirmed to drop the size of executables on windows back to a more reasonable
size (2.0MB, as they were before).

Closes #14144

Closes #14231 (mk: Don't run benchmarks with `make check`)
Closes #14215 (std: Modify TempDir to not fail on drop. Closes #12628)
Closes #14211 (rustdoc: functions in ffi blocks are unsafe)
Closes #14210 (Make Vec.truncate() resilient against failure in Drop)
Closes #14208 (Make `from_bits` in `bitflags!` safe; add `from_bits_truncate`)
Closes #14206 (Register new snapshots)
Closes #14205 (use sched_yield on linux and freebsd)
Closes #14204 (Add a crate for missing stubs from libcore)
Closes #14203 (shootout-mandelbrot: Either 10-20% or 80-100% improvement.)
Closes #14202 (Add flow-graph visualization (via graphviz) to rustc)
Closes #14201 (Render not_found with an absolute path to the rust stylesheet)
Closes #14200 (std cleanup)
Closes #14189 (Implement cell::clone_ref)

Per discussion with @alexcrichton, this is a free function.

Each test works by rendering the flowgraph for the last identified
block we see in expanded pretty-printed output, and comparing it (via
`diff`) against a checked in "foo.dot-expected.dot" file.

Each test post-processes the output to remove NodeIds ` (id=NUM)` so
that the expected output is somewhat stable (or at least independent
of how we assign NodeIds) and easier for a human to interpret when
looking at the expected output file itself.

----

Test writing style notes:

I usually tried to write the tests in a way that would avoid duplicate
labels in the output rendered flow graph, when possible.

The tests that have string literals "unreachable" in the program text
are deliberately written that way to remind the reader that the
unreachable nodes in the resulting graph are not an error in the
control flow computation, but rather a natural consequence of its
construction.

Passing `--pretty flowgraph=<NODEID>` makes rustc print a control flow graph.

In pratice, you will also need to pass the additional option:
`-o <FILE>` to emit output to a `.dot` file for graphviz.

(You can only print the flow-graph for a particular block in the AST.)

----

An interesting implementation detail is the way the code puts both the
node index (`cfg::CFGIndex`) and a reference to the payload
(`cfg::CFGNode`) into the single `Node` type that is used for
labelling and walking the graph.  I had once mistakenly thought that I
only wanted the `cfg::CFGNode`, but for labelling, you really want the
cfg index too, rather than e.g. trying to use the `ast::NodeId` as the
label (which breaks down e.g. due to `ast::DUMMY_NODE_ID`).

----

As a drive-by fix, I had to fix `rustc::middle::cfg::construct`
interface to reflect changes that have happened on the master branch
while I was getting this integrated into the compiler.  (The next
commit actually adds tests of the `--pretty flowgraph` functionality,
so that should ensure that the `rustc::middle::cfg` code does not go
stale again.)

1. Only insert non-dummy nodes into the exit map.

2. Revise handling of `break` and `continue` forms so that they are
   not treated as if control falls through to the next node (since it
   does not, it just jumps to the end or start of the loop body).

3. Fixed support for return expression in flow graph construction.

Refine lifetimes in signature for graph node/edge iteration methods.

Added `pub` `node_id` and `edge_id` methods that correspond to
NodeIndex and EdgeIndex `get` methods (note that the inner index is
already `pub` in the struct definitions).  (I decided that `get()`,
used internally, just looks too generic and that client code is
clearer with more explicit method names.)