Part of PR 75

pointers passed to them whenever necessary. Otherwise it is possible the
caller may have overwritten (or deallocated) the original string data
when a later ENGINE operation tries to use the stored values.

Submitted by: Götz Babin-Ebell <babinebell@trustcenter.de>
Reviewed by: Geoff Thorpe
PR: 98

not return immediately since that leaves a locked lock.

consistent with the rest of the AEP functions

CRYPTO_LOCK_RAND...

lets change our prefix to AEPHK_R_.  Otherwise, we get very mysterious
errors because we happen to redefine AEP_R_OK and AEP_R_GENERAL_ERROR.

that were never part of the engine framework.

The aep and sureware implementations are taken directly from 0.9.6c
[engine] and have been modified to fit the newer engine framework and
to be possible to build shared libraries of.

The aep implementation has gone through quite a bunch of tests and is
cleaned up (there were some misunderstandings in it about how to use
locks).

The sureware hasn't been tested at all in this incarnation and is
basically a quick hack to get it to compile properly.