Work-around 'static bound requirement in io::with_bytes_reader (note: does not fix #5723, interface still unsafe)

flat_map_ produces an iterator that maps each element to an iterator,
and yields the elements of the produced iterators.

This is the monadic bind :: M a -> (a -> M b) -> M b  for iterators.

Named just like the vec method, but with a trailing underline until the
method resolution bug is resolved.

We discussed the name chain_map, but I decided to go with flat_map_ for consistency with vec.

Since it.map(f).flatten()  would be the same as it.flat_map(f), we could choose
to just implement a flatten method instead. Either way the possibilities are the same but flat_map is more convenient.

This allows macros to both be conditionally defined, and expand
to items with #[cfg]'s.

This seems to have a performance improvement, e.g. for `std`:

```
# Before 
time: 1.660 s   expansion
time: 0.125 s   configuration
# After
time: 0.080 s   configuration 1
time: 1.127 s   expansion
time: 0.132 s   configuration 2
```

And for `extra`:

```
# Before
time: 0.593 s   expansion
time: 0.062 s   configuration
# After
time: 0.047 s   configuration 1
time: 0.147 s   expansion
time: 0.058 s   configuration 2
```

(This seems a little peculiar, but it is possibly because the expansion AST traversal is very slow, so removing as much as possible as early as possible has big benefits.)

This allows macros to both be conditionally defined, and expand
to items with #[cfg]'s.

This PR contains no real code changes. Just some documentation additions in the form of comments and some internal reordering of functions within debuginfo.rs.

Reopening of #7031, Closes #6963

I imagine though that this will bounce in bors once or twice... Because attributes can't be cfg(stage0)'d off, there's temporarily a lot of new stage0/stage1+ code.

Closes #7071

Finally rename finalize to drop.
Closes #4332.

Sets the stage for further cleanup (especially mass-slaughter of `@`)

the maps are being migrated to external iterators

Fix #7322.

I started out with a band-aid approach to special-case the duplicate module error using `is_duplicate_module`, but thought this would be better in the long term.

The "first definition of ..." error string reported by add_child() looks
different from similar messages reported by other functions.  Fix this.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>

add_child() is responsible for reporting errors about type, value, and
module duplicate definitions.  Although it checks for all three, it uses
namespace_to_str() to convert a Namespace value into a string before
printing an error like:

  error: duplicate definition of type `foo`
                                 ^^^^
  note: first definition of type foo here:
                            ^^^^

Unfortunately, this string can only be one of "type" or
"value" (corresponding to TypeNS and ValueNS respectively), and it
reports duplicate modules as duplicate types.

To alleviate the problem, define a special NamespaceError enum to define
more specialized errors, and use it instead of attempting to reuse the
Namespace enum.
Reported-by: NCorey Richardson <corey@octayn.net>
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>

This is an attempt at a smaller request than #7113, it's just the first two commits

This adds a `#[no_drop_flag]` attribute. This attribute tells the compiler to omit the drop flag from the struct, if it has a destructor. When the destructor is run, instead of setting the drop flag, it instead zeroes-out the struct. This means the destructor can run multiple times and therefore it is up to the developer to use it safely.

The primary usage case for this is smart-pointer types like `Rc<T>` as the extra flag caused the struct to be 1 word larger because of alignment.

This closes #7271 and #7138

This sets the `get_tydesc()` return type correctly and removes the intrinsic module. See #3730, #3475.

Update: this now also removes the unused shape fields in tydescs.

This adds both `static mut` items and `static mut` foreign items. This involved changing far less code than I thought it was going to, but the tests seem to pass and the variables seem functional.

I'm more than willing to write more tests, so suggestions are welcome!

Closes #553

I also cleaned up the warnings.