Session: id based on sha1/base64 instead of md5^2 in non-uuid fallback

```
This can prevent issues when Python uses hashes implemented by OpenSSL
library and is run in FIPS mode [*] (i.e., md5 not allowed by default),
at least if for some reason (incl. future removal, see note below)
the uuid variant is not used.

Also I consider using single iteration of sha1 to still maintain better
properties security-wise than two iterations of md5.

Because hexdigest of sha1 hash is 40-32=8 characters longer and hence
new "cannot store the session data, path too long" regression (in case
of file backend, additionaly amplified by "initial segmentation depth"
of 3, but perhaps similarly with other backends) might appear, the raw
digest (20  bytes) is being base64 encoded (ala urlsafe_b64encode),
and the suffix padding (single '=' in this case) is being removed,
leading to 27 characters.  This also means higher information density
of the identifier (20 effective bytes represented by 27 characters
rather than 16 bytes represented by 32 characters as with md5 hexdigest)
and in turn in more powerful "initial segmentation" in case of file
backend with up to 64 sibling directories as opposed to former 16).

Furthermore, such change should be unobtrusive in any case as the code
path only affects newly created sessions...

Note: based on a test on 2 machines and using Python v2.7.3 and
v3.2.3/v3.3.0, uuid4 variant (default for Python 2.5+) appears to be
twice as slow as the fallback variant incl. this changeset, which
in turn is slower than original double md5 version by about 30%.
Just that the randomness/complexity tradeoff of uuid4 might be
worth reconsidering.

[*] for instance, FIPS mode in Fedora:
    https://bugzilla.redhat.com/show_bug.cgi?id=805538#c0

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
```