Remove the unnecessary lang items for Send and Sync

[bstrie]

I remember @huonw telling me long ago that these lang items are unnecessary, though I don't remember if there's a good reason for why they haven't been removed yet.

[eefriedman]

The lang-items are currently necessary for the following testcase to compile:

fn main() {
    let _x : Box<Fn()+Send+Sync>;
}

[Manishearth]

They are necessary for the following reasons:

• Sync has some interaction with #[thread_local] or static mut or something
• Box<Trait+Marker> only works for language-blessed marker traits
• I believe the compiler also heavily caches these traits

These are mostly edge cases (and even if they weren't there we would still be able to do everything), which is why we like to say that Send/Sync could be created in a library with minimal differences. But that doesn't mean they should.

[bstrie]

@Manishearth RE: could vs should, IMO in the long term the caching argument is the only defensible one because that's the only one that can be considered an ignorable implementation detail. We've got this whole OIBIT thing for a reason, let's not count on lang items to shore up language deficiencies forever. (And even if OIBITs are currently unstable, presumably they won't be unstable forever.)

[arielb1]

@Manishearth

Ordinary statics are required to be Sync, as they are shared between all threads in a process.

[steveklabnik]

Triage: no changes.

Tagging with lang and libs, since this would have to be coordinated between the two of them.

[Manishearth]

I don't think this is a libs issue; it's really a T-compiler issue, maybe a lang issue. The end result of this issue is that the final public language shouldn't change at all, so the lang part sort of drops out. idk.

Now, I guess a holistic solution for these would be to keep Sync a lang item (for statics) and invent a new internal attribute for traits which are allowed to be used in objects.

[leoyvens]

#45772 did all we could do here by removing the send lang item. We need sync for statics. @Mark-Simulacrum this may be closed.