Tracking issue: Replacing an struct/enum/union with a trait or function (or vice versa) should not trigger "item missing" lints

[obi1kenobi]

If an item importable by some path (say, a struct) is replaced by another kind of item (say, a trait) importable under the same path, this should not be reported as the original item being missing — this will unnecessarily confuse users, and the replacement isn't even necessarily a breaking change (e.g. see #297).

The resolution of #297 (via #306, #308, and #312) resolves the cases where a struct is converted into an enum or union (whenever unions in general are implemented). This resolves the most immediately painful aspect, but is not a full resolution.

Remaining tasks:

• Split up "enum removed" from "enum changed to struct/union" checking #302
• schema change: Make Importable a subtype of Item trustfall-rustdoc-adapter#35
• don't report structs as missing if they change to trait or fn
  • requires Make Importable a subtype of Item trustfall-rustdoc-adapter#35
  • struct -> trait is always breaking because bare trait returns from functions aren't allowed, they require dyn as of a couple of Rust editions ago)
  • constructible struct -> fn is always breaking because even tuple structs can be constructed with curly-braces syntax
  • structs with pub methods (either inherent or via trait) -> fn is always breaking because those methods can't get called
  • struct -> fn is probably always breaking, probably safe to assume it
• ensure unions aren't reported as missing if they change to struct/enum
  • requires Implement the Union type, making union types queriable  trustfall-rustdoc-adapter#36
• unions shouldn't be reported as missing if they change to trait/fn
  • requires Implement the Union type, making union types queriable  trustfall-rustdoc-adapter#36 and Make Importable a subtype of Item trustfall-rustdoc-adapter#35
• ensure functions aren't reported as missing if they change to another item kind
  • it's possible that function -> constructible tuple struct (and perhaps unit struct) might not always be a breaking change
  • it's also possible that function (in an appropriate module) -> enum with the module name + tuple (and maybe unit) variant with the function name might also not be breaking: X::Foo where X is a module or enum, Foo is a function or variant.
• ensure traits aren't reported as missing if they change to another item kind
  • this is always breaking, can't do X: TraitName bounds with anything but a trait