Support SPDX license identifiers

[Frixuu]

Current licensing options have several issues:

• They are too ambiguous. Is "GPL" version 2 or 3? Does it allow later revisions? How many clauses is "BSD"? SPDX IDs are more specific.
• They do not give enough choice. What if somebody wants to release a library under AGPL, MPL or Zlib? SPDX defines over 500 license identifiers, including a bunch approved by OSI/FSF/whomever.
• They are not a standard. SPDX identifiers are supported (or sometimes even required) by NPM, Nuget, Composer, Maven, RubyGems, Conan etc.

[tobil4sk]

This was discussed previously in #52, but I suppose with an official list this is a more achievable task.

[Simn]

I personally don't care about this stuff at all and it's a layer of concern that I prefer to not deal with. But as long as I can still install haxelibs without hiring a lawyer I won't get in your way either.

[joshtynjala]

I just ported a library from another language with an open source license that is not supported by haxelib.json. I guess I'm just going to put Public, even though that's not the actual license. The actual license has a SPDX license identifier, though.

For reference, npm allows custom licenses that aren't SPDX:

If you are using a license that hasn't been assigned an SPDX identifier, or if you are using a custom license, use a string value like this one:

{ "license": "SEE LICENSE IN " }