BatteryManager: Incorporate methods rather than include

[hamishwillee]

Fixes #3316

Copy-paste of methods from EventTarget, and removal of additional chrome/mozilla methods.

@wbamberg Set you as reviewer for this first one.

[wbamberg]

Sorry if I wasn't clear in #3316. I don't think the fix here is to copy/paste the EventTarget methods, I think it's just to point to EventTarget.

If you look at, say, https://developer.mozilla.org/en-US/docs/Web/API/AudioContext#methods, it just says:

Also inherits methods from its parent interface, BaseAudioContext.

...it doesn't copy/paste those methods into this page.

(There is quite a lot of variability in how we handle inheritance across the Web/API docs, but this - pointing to the parent but not copying the list of features - is the most common. And even within this general approach there's a lot of variation in the exact words (see e.g. https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#methods). It would be great to have more consistency here, but that's probably out of scope for this bug :).)

[hamishwillee]

@wbamberg Arrgg, you were clear, but I clicked another example :-(.

I have fixed this up in-line with the same approach. I see no reason we can't propose some standard text for fixes to at least reduce the variation.

Minor point, but should we link direct to the methods section? It makes little difference here, but if you have a big base class then you'll be looking around for it. Note that to do this we can't use {{domxref("EventTarget","EventTarget","Methods")}} - the link works but it renders as EventTarget.Methods

[wbamberg]

Looks great, thanks @hamishwillee !

I see no reason we can't propose some standard text for fixes to at least reduce the variation.

We can propose it, but without linters to check I doubt it would be very effective. But maybe I'm just bitter :).

I think linking to #methods is a good idea, but again it would be a thing we'd want to do across all the docs.