Make `Sel` an opaque struct like `Ivar`, `Method,` `Class`, `Protocol` and `Object`

[madsmtm]

The discrepancy between usage of Class/Object/... and Sel annoyed me, the others were used behind pointers / references, while Sel was consumed directly.

This changes the definition of Sel to be like the other types (so it has to be used as &Sel), and also opens up for the possiblity of non-static selectors (if that ever becomes a thing).

This is a breaking change, but fortunately most cases where Sel is used in user code (e.g. add_method) the error is caught at compile-time, with recommendations on how to fix it.

[SSheldon]

Selectors in objective-c are treated like they have copy semantics. Why does the discrepancy here annoy you? Is there a benefit to having a lifetime on selectors? I don't believe there will be a need for non-static selectors.

If anything, perhaps making Class/Method/etc references was the mistake, because those lifetimes are barely ever useful in practice. (idk if anything ever actually gets unregistered from the objc runtime)

[madsmtm]

Mostly it just confused me since all the other types worked the other way.

But I think it actually would make the workings of Sel more explicit: Since Sel::register would return a static reference, you'd be able to instantly see "hey, this is Copy and the Sel doesn't stop being valid when I drop it". Additionally Sel::name would automatically return &'static str (actually, maybe it should do that now too?).

But no, I don't think you can actually get a non-static selector.

Classes however can be destroyed with objc_disposeClassPair, and we might at some point want to make an API that allows control over this (right now we're just "leaking" classes). So I think working with Class behind references is appropriate for now.