Fix immediate error in hash_identifier in case of FIPS mode (#6)

After rethinking what to do with the issue at hand (Bitbucket issue 8
resurrected as GitHub #6, in parallel to rhbz#746118) and querying
various code databases (incl. GitHub and Ohloh and general search
engines) to validate that my intention is not going to be disruptive
to open source projects with weberror in their stacks, I've decided
(primarily because of lack of permission from @jaredjennings) to go
another way.

It's based on the fact that the product of hash_identifier sits in
CollectedException instance as its identification_code attribute,
but hardly ever gets used (except for non-public code, maybe),
which is a waste.  On the other hand, this "feature" was there
from ~beginning so should probably be retained.

Good way to fight with waste is to be lazy and as the arranged
scenario supports such behavior reasonably well (there will be
limitations but the doctest passes OK without any change) and as
the import of md5 functionality (unlike the actul use) is non-issue
in FIPS mode, we can simply push possible point of failure out of
the main unconditional flow, making the respective hash-based
value computed on-demand as in lazy evaluation.  This doesn't
cover eveything, but weberror becomes well-behaved even in FIPS
mode for vast majority of dependent projects with this change.

The code should be compatible with Python 2.4+, definitely works
with newer ones (Python 3 line is not supported due to syntax used
on other places in the modified file).

Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Merge pull request #7 from jnpkrn/issue8

Fix immediate error in hash_identifier in case of FIPS mode (#6)