We've had these in this repository since the exception landed in
e355521 (Adding exception: Nokia-Qt-exception-1.1, 2017-02-05, spdx#354),
and they've been in license-list-data since the exception landed there
in spdx/license-list-data@cec28dc7 (Updated JSON exception files,
2016-04-16).  I haven't bothered with an <alt> tag because the
matching guidelines have [1]:

  5.1.3 Guideline: Quotes Any variation of quotations (single, double,
  curly, etc.) should be considered equivalent.

That doesn't explicitly say that you can add/remove quotes in the
general case.  And maybe that's intentional.  But if we treat the
whole unit as a quote (going from quad-quotes to double-quotes) then
this change should have no impact on matching.

In practice, I think it's unlikely that folks copied the exception
with the quad-quotes.  And the upstream linked from our XML is pinned
to a specific revision and only uses double-quotes.

[1]: https://spdx.org/spdx-license-list/matching-guidelines

And deprecate the old ID, which had two problems [1]:

* Qt no longer belongs to Nokia, and they've changed the title
  upstream to reflect that.
* Qt has another exception for GPL3, and the old ID didn't mention the
  target license.

This commit adds the new identifier and deprecates the old one in its
favor.

I've used Qt-LGPL-exception-1.1 instead of Kai's suggested
Qt-exception-LGPL-1.1 to match the {name}-{target}-exception-{version}
pattern suggested by the existing i2p-gpl-java-exception.

I've set an <alt> in the exception title so it will match the old
"Nokia " prefix, the current "The Qt Company " prefix, or no prefix at
all.  I've used "The Qt Company " prefix in the test file to match the
upstream text (the test is a copy/paste of the upstream text with
trailing whitespace removed).

[1]: https://lists.spdx.org/pipermail/spdx-legal/2018-March/002511.html
     Subject: New License/Exception Request: Qt-LGPL-exception-1.1
     Date: Fri, 23 Mar 2018 15:39:54 +0000
     Message-ID: <HE1PR0202MB2571F0B9F0305FA2150A428F98A80@HE1PR0202MB2571.eurprd02.prod.outlook.com>

spdx-tools can't handle this at the moment:

On Fri, Mar 23, 2018 at 11:36:30PM +0000, Gary O'Neall wrote [1]:
> The second problem is including the trailing space in the matching
> text.  Since the matching software tokenizes and removes white
> space, it doesn't include the space in the match.  To work around
> this, just don't include any preceding or trailing white space in
> the match.

And while the extra leading whitespace in the no-prefix case isn't
very elegant, it's not a problem either.

[1]: spdx#627 (comment)

The alternation operator (|) is commutative in the POSIX spec, which
has [1]:

> If the pattern permits a variable number of matching characters and
> thus there is more than one such sequence starting at that point,
> the longest such sequence is matched.

Testing with a few engines, here are some that match POSIX:

  $ echo abc | grep -Eo '|a|ab'
  ab
  $ python -c 'import regex; print(regex.match("|a|ab", "abc", regex.POSIX).group(0))'
  ab  # Background in https://bitbucket.org/mrabarnett/mrab-regex/issues/150
  $ psql -Atc "select substring('abc' from '|a|ab')"
  ab

The docs for PostgreSQL are somewhat complicated, but for two or more
branches connected by the | operator they are always greedy [2].

Here are some engines that prefer the left-most branch:

  $ python -c 'import re; print(re.match("|a|ab", "abc").group(0))'
  $ python -c 'import regex; print(regex.match("|a|ab", "abc").group(0))'
  $ node -e 'console.log("abc".match(/|a|ab/)[0])'  # [3]
  $ ruby -e 'print "abc".match(/|a|ab/); print "\n"'  # [4]

Go's stdlib provides both left-most-branch [5] and longest-match [6]
implementations.

So the old order was compliant with POSIX EREs (as referenced in
schema/ListedLicense.xsd), but this commit sorts the branches for
longest-match-first for compatibility with engines that break POSIX
and prefer the left-most branch.

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_01_02
[2]: https://www.postgresql.org/docs/10/static/functions-matching.html#POSIX-MATCHING-RULES
[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#special-or
[4]: https://ruby-doc.org/core-2.5.0/Regexp.html#class-Regexp-label-Alternation
     Although these docs don't have much to say on longest-match
     vs. left-most branch.
[5]: https://golang.org/pkg/regexp/#Compile
[6]: https://golang.org/pkg/regexp/#CompilePOSIX