custom.lds.S: use SORT() instead of SORT_BY_INIT_PRIORITY()

SORT_BY_INIT_PRIORITY() was added with the goal of meshing
.ctor .dtor into .init_array and .fini_array respectively. This
was done to avoid the need for the associated (relative) relocations,
and avoids backwards disk seek on startup (since while .ctors are
processed backwards, .init_array is processed forward) [0] [1].
This later aspect of this change is considered a performance gain
for C++ applications such as Mozilla or Google Chrome. There are
a series of compatibility requirements in place to help sort out old
expected constructor section priority annotations, this is all
now moved onto .init_array. The SORT_BY_INIT_PRIORITY() is very
specific to .init_array sections though, so you'll need to use
__attribute__ ((section (".init_array.65530"))) for instance.
We want the freedom to use custom sections, but in principle
also sort numerically. We don't have support for that yet and even
if we did this would require binutils >= 2.22. As per the kernel's
documentation [2] the current minimum requirements for binutils
is 2.12.

The only reason why SORT_BY_INIT_PRIORITY() *works* is the
implementation resorts back to SORT_BY_NAME() in the case that
the detected priority for both sections it is comparing is 0,
which will be the case for any section that uses
SORT_BY_INIT_PRIORITY() if it is not prefixed by ".init_array.",
".fini_array.", ".ctors.", or ".dtors.". For more details refer
to the implementation of get_init_priority() in binutils
ld/ldlang.c.

The old SORT() could still be used with its own numeric section by
just using your own macros to specify the priority numerically, even
though it will sort in ascending order by name. I'll note that
SORT() is just an alias for SORT_BY_NAME(), this is really the
implementation we'd be relying on.

As far as SORT() / SORT_BY_NAME() is concerned -- the only concern
I can come up with after reading the implementation details of
SORT_BY_INIT_PRIORITY(), even though we won't use it, is that
there are no precise semantics gauranteeing sort order accross
different object files: *technically* the support is there and
this works but as far as I can tell these gaurantees are not
clearly documented formally as part of binutils.

Note that although SORT_BY_INIT_PRIORITY() was designed
specifically for init_array stuff, I noted that it still
resorts to SORT_BY_NAME() as a backup for non init_array
section names, and this is what we want. So if we really
wanted to annotate we want SORT_BY_INIT_PRIORITY() style
of behaviour to enforce a numeric priority identity
in future binutils releases we *could* in theory just
use SORT_BY_INIT_PRIORITY() to annotate all this and the
desire to have this in future binutils *but* not only would
this likely require a separate macro that is not specific
to init, perhaps SORT_BY_PRIORITY(), but also bumping the
binutils minimum requirements from 2.12 to 2.12 or later
if we want a generic new SORT_BY_PRIORITY().

So -- for now just use SORT_BY_NAME().

[0] https://gcc.gnu.org/ml/gcc/2010-12/msg00344.html
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
[2] Documentation/Changes as of linux-next next-20151012

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>