Tracking issue for builtin derive macros

• #2154
• Validate #[derive] attribute and collect the attribute's inputs. collect_derives in rustc/compiler/rustc_expand/proc_macro.rs
• Add new DeriveMacroAccumulator visitor to visit all required fields/variants of a struct/enum/union getting "derived"

This is different from custom derive macros, which will only receive a token stream - we have more information within the compiler and can make use of them

• Handle all builtin derives (#927): Clone, Copy, Debug, Default, Hash, {Partial}Eq, {Partial}Ord)
• Add good typechecking errors for when derive constraints are not met:

struct S;
#[derive(Clone)]
struct SuperS(S);

should fail because S does not implement Clone. The code produced by the macro should be similar to this:

struct S;

struct SuperS(S);

impl Clone for SuperS {
    fn clone(&self) -> Self {
        Self(self.0.clone())
    }
}     

Without any derive-specific behavior, we'll get an error about how self.0 does not implement clone, which is true but not helpful for users as the code responsible will have been generated by the compiler.

During typechecking, we should check that the members of a type getting derived also implement the trait being derived, and produce errors more related to deriving ("consider annotating S with #[derive(Clone)]" etc)

• Deriving Clone on a union requires that the union is Copy
• Support deriving on statements inside a BlockExpr
• Implement proper way to access a statement's outer attributes if that statement is an item
• Ignore impls that were #[automatically_derived] in lints
• #2238
• Decide when to add #[inline] to generated impl functions

This is a tracking issue for builtin derive macros, with one entry point named: collect_derives in rustc/compiler/rustc_expand/proc_macro.rs. Review the linked #2154 and the remaining checklist items first; the work is done only when the listed derive handling, diagnostics, union and block support, lint behavior, and inline decisions are addressed.