Move Md5 password hashing to server side

[tobil4sk]

This changes the api version to 4.0, where hashing is done server side. For now, old clients are still allowed to use api version 3.0 and hash on the client. Later on, submission and registration can be disabled for api version 3.0 so that the migration can take place.

This makes it easier to deal with #314 (also see the thread regarding server side hashing).

[Simn]

FWIW I'm in favor of this change and think we should move forward with this. I think we all agree that this should be done, the only remaining question is if it should also still be done on the client-side. @andyli seems to be the only one in favor of that, so I'd like to sort that out before comitting to anything.

[tobil4sk]

To reiterate, these are the reasons why I would recommend against client side hashing:

• Client side hashing leads to overall worse security, because it delays security changes. Any changes to hashing require breaking client compatibility, which means that the hashing upgrades are very tedious and will end up getting put off, like the Md5 migration has been put off since 2008 when Md5 was declared broken. If we stick to only server side hashing, future hashing related security improvements can be done seamlessly which would make haxelib more adaptable to future security requirements.
• Client side hashing does not actually provide any extra protection to haxelib user accounts, because the hash produced by the client effectively takes the place of the password and gives access to the account.
• Client side hashing requires a Haxe implementation of a hashing algorithm, which wouldn't be audited and is insecure, given that well audited and well established implementations already exist. If we don't do this, the haxelib client will be stuck running on Neko.
• Client side hashing would require the client getting a salt from the server, which adds complexity.
• With https, the password is already encrypted when sent between the client and server. If the server code was compromised there would be a threat, but at that point there are bigger things to worry about because there are much nastier things an attacker could do with that kind of access.