resourceloader: Remove obsolete aliases from closure

resourceloader: Remove obsolete aliases from closure

== jQuery

ResourceLoader wraps and executes all modules in the system via
a closure that explicitly binds '$', 'jQuery'. This means there is
no point in aliasing jQuery to $ in every single file.
ResourceLoader already does this.

This is a very very old habit that was introduced in 2009 when we
didn't have ResourceLoader and were concerned with wikis loading
their own copy of jQuery that could redefine the global 'jQuery'
and '$' variables. We simply hoped that "our module" initialised
before "that module" cache the reference we got in the file closure.

Then in 2010, when building ResourceLoader, we found this didn't
always work. And we also sometimes forgot to add the closure.
Which is why in 2010 (before ResourceLoader went to prod, in 2011)
we fixed the above issue in ResourceLoader itself by "magically"
providing a private binding to '$' and 'jQuery' in every
mw.loader.implement() closure. (r79246, bd93eeb85).

So, these in-file closure references are redundant.
And have been since 2010.

== jQuery, again.

While redundant, they remained in most files. Harmless, right?

However, that same problem of duplicate jQuery copys on a page
came up again in 2013. Why did our magic binding not work?

It was *because* the file also did its own binding:

1. ResourceLoader stores reference to proper jQuery.
2. ResourceLoader provides private reference to it as '$'.
3. .. time passes ..
4. Module executes, and is given the proper jQuery via the
  private '$' reference. The module file ignores this because
  it instead looks up current jQuery, and caches that.

So, we expande the magic binding to also bind the name 'jQuery'.
(2013-2014; 5742c1f38527).

== mediaWiki

We export the binding as 'mw' and 'mediaWiki'. We internally
mostly use 'mw' (in HTML, and documentation, and the canonical
name in the JSDuck index). But, rather than using the shorter name,
we use the longer name and alias it in every single file.

There was never a concern about this global being redefined
as far as I know. However, if that happens one day, we should..
provide a magic binding for it.

Change-Id: Id6d13bbea6927a4c7354ca1edd98f13f0fae30c1