around the callbacks required in the LHASH code for the "doall" functions.

Also - fix the evil function pointer casting in the two lh_doall functions
by deferring to a static utility function. Previously lh_doall() was
invoking lh_doall_arg() by casting the callback to the 2-parameter
prototype and passing in a NULL argument. This appears to have been working
thus far but it's not a hot idea. If the extra level of indirection becomes
a performance hit, we can just provide two virtually identical
implementations for each variant later on.

functions need to be constified, and therefore meant a number of easy
changes a little everywhere.

Now, if someone could explain to me why OBJ_dup() cheats...

casts) used in the lhash code are about as horrible and evil as they can
be. For starters, the callback prototypes contain empty parameter lists.
Yuck.

This first change defines clearer prototypes - including "typedef"'d
function pointer types to use as "hash" and "compare" callbacks, as well as
the callbacks passed to the lh_doall and lh_doall_arg iteration functions.
Now at least more explicit (and clear) casting is required in all of the
dependant code - and that should be included in this commit.

The next step will be to hunt down and obliterate some of the function
pointer casting being used when it's not necessary - a particularly evil
variant exists in the implementation of lh_doall.

I didn't apply all his patches yet, since I have some hesitance about
unconstifying.  To be pondered.

like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.

eliminate some of the -Wcast-qual warnings (debug-ben-strict target)

Submitted by:
Reviewed by:
PR:

1. The already released version was 0.9.1c and not 0.9.1b

2. The next release should be 0.9.2 and not 0.9.1d, because
   first the changes are already too large, second we should avoid any more
   0.9.1x confusions and third, the Apache version semantics of
   VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
   .2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------