Remove Root::r() and uses of it

[michaelwu]

Root implements Deref, so r() isn't necessary.

Deref on Root was implemented in #6150

[fitzgen]

Working on this.

[fitzgen]

Ok, so I made some progress, but quickly got bogged down in the following issue:

We implement .r() not only on Root but also on Option<Root<T>> and Option<Option<Root<T>>> via the helper traits RootedReference<T> and OptionalRootedReference<T>. Those don't have Deref impl'd, and IIUC can't have Deref impl'd because neither Deref nor Option are owned by servo.

Does it make sense to remove .r() usage only from Root and not the (just as common) others? I feel it may be worth preserving the consistency that exists now.

To be honest, most of the changes I've done so far (before I got bogged down in codegen and the above issue) haven't been of the form

foo.r().bar() --> foo.bar()

but of the form

func(foo.r()) --> func(&*foo)

While the former is surely desirable, the latter feels a whole lot more "meh", especially in light of the inconsistency that will arise when dealing with Option<Root<T> and Option<Option<Root<T>> which will still need to use func(foo.r()).

Thoughts?

(cc @jdm who I was pointed towards on irc)

[michaelwu]

FWIW, I don't really like RootedReference or OptionalRootedReference. Had too many changes in the smup already so I didn't experiment with removing them, but those traits always struck me as a bit odd.

[frewsxcv]

I don't have any grand thoughts on the questions raised, but if work has already been put into this, it might be worth opening a PR just so it doesn't get bitrotted (as a result this PR would be split up into multiple PRs)

[jdm]

Given that this isn't as clear-cut as originally believed, and since I agree with @fitzgen's ambivalence about the foo.r() -> &*foo transformation, I'm inclined to close this.