make file2key reject E* backend keys with a long extension

I am not happy that I had to put backend-specific code in file2key. But
it would be very difficult to avoid this layering violation.

Most of the time, when parsing a Key from a symlink target, git-annex
never looks up its Backend at all, so adding this check to a method of
the Backend object would not work.

The Key could be made to contain the appropriate
Backend, but since Backend is parameterized on an "a" that is fixed to
the Annex monad later, that would need Key to change to "Key a".

The only way to clean this up that I can see would be to have the Key
contain a LowlevelBackend, and put the validation in LowlevelBackend.
Perhaps later, but that would be an extensive change, so let's not do
it in this commit which may want to cherry-pick to backports.

This commit was sponsored by Ethan Aubin.

doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn

@@ -36,12 +36,15 @@ A few other potential problems:
   git-annex has ever supported (probably < 20 bytes or so), which would
   be less than the size of the data needed for current SHA1 collision
   attacks. Presumably aa chosen-prefix attack would need a similar amount of
-  data.
+  data. Update: Now done; git-annex refuses to use keys with super
+  long extensions.
 
 * It might be possible to embed colliding data in a specially constructed
   key name with an extra field in it, eg "SHA256-cXXXXXXXXXXXXXXX-...".
   Need to review the code and see if such extra fields are allowed.  
 
   Update: All fields are numeric, but could contain arbitrary data
-  after the number. This has been fixed; git-annex refuses to parse
+  after the number. Could have been used in a chosen-prefix attack
+  (posibly; would require field to come after key name data) or
+  preimage attack. This has been fixed; git-annex refuses to parse
   such fields, so it won't work with files that try to exploit this.