Use new interface 'SGP'

There is no need to create an concatenated buffer of 'password:domain'
since all we do is to feed the bytes 1:1 through Md5. This changes
'func hashPassword(out []byte, password []byte)' to
'func hashPassword(out []byte, pw_parts ...[]byte)' and reduces the
amount of allocations.

Additionally, we also allocate a new temporary buffer in 'hashPassword'
on each call, just to throw it away at the end of the function.

'SGP' defines an interface which allows to implement a new method (sha1
comes to mind, see supergenpass.com). 'SGPMd5' implements 'SGP', reduces
the amount of allocations
Remove unused code
Add Sha512 variant of supergenpass

This commit provides the Sha512-based variant of supergenpass. It adds
the -sha flag.
Use simple code to check password validity instead of RE

Instead of having a (quite complex) regular expression to check 3 things
in the generated password we use now a simple loop + some if-conditions.
This also reduces the risk of having traces of the checked passwords
somewhere in the regular expression code.

Additionally:

* Enforce a minimum password length
* Fix spelling in error messages
* Move tests
Reduce needed buffers

We actually do not need 2 buffers to rotate the generated passwords around,
we only need one. This simplifies the code a bit.
Rewrite replaceLikeSupergenpass()

supergenpass.com takes the output of md5/sha512 and pipes it through
plain base64. This base64 encoded string gets modified a little bit: '/'
becomes '8', '+' becomes '9' and the padding '=' becomes 'A'.

The first optimization is to do the char-swapping while base64-encoding:

  var sgpBase64 *base64.Encoding
  ...

  sgpBase64.Encode(pw, digest)

The 2nd optimization:  the last 2 bytes of either base64(md5(input))
or base64(sha512(input)) are always "==":

  sgpBase64.Encode(pw, digest)
  sgp.FixPadding(pw)

These 2 optimizations are the core of this commit, the rest is just some
reordering of code.
Decrease the size of the working buffer

This commit is essentially the port of an optimization I found for
[csgp][1]: to generate a password via Md5 we only need a Md5 hasher
and a working buffer of 24 bytes (base64.StdEncoding.EncodedLen(md5.Size)).
The 16 bytes for the raw Md5 digest are stored inside the 24 byte buffer
like this: [24......[16..............]]. This works because:

* The password parts end up directly as in the Md5 hasher (first round)
* The md5-state is copied over into the 16byte block
* The 16byte block gets base64-encoded. The b64-encoder chases the
  currently processed byte from the 16byte block but never catches
  up; except for the last round. In that round, any trace of the raw
  md5-state got erased by the base64-version of it:
           +--------+
       [aaaa.......[111.........]]
       [aaaabbbb...[111222......]]
       [aaaabbbbccc[c11222333...]]

* The 24byte buffer is then feed into a md5-state and
  the whole process repeats.

[1]: https://github.com/mgumz/csgp
Use golang.org/x/crypto/ssh/terminal

Other: minor cleanup
Merge pull request #3 from mgumz/master

Sha512, less memory usage, no regexps, etc.