A first crack at an 'encrypt' callback.

This is very much a WIP with tons of debug.  I had to add a size
parameter to the crypt callback but more importantly having just
one callback makes the function ugly (I think).  This is on account
of having to detect when a call to the 'Finalize' routine is
necessary.

Basically we have to deduce when the current call to the function
will be the last.  Because we only encrypt data when the input
buffer is full, on the surface this seems like a simple size check
on the buffer we're encrypting.  We end up with a weird edge case
though when the input data size is a multiple of the input buffer
size.  Thus we can't detect the final buffer until we get asked to
encrypt 0 bytes of data.

This means we either end up with an extra call to the 'update'
function which really isn't a big deal for efficiency but it's very
inelegant.  I'm starting to think it may be better to use two
callbacks, one for update and one for finalize.  This would let the
main processing loop which has the data necessary to identify when
we've received our last input buffer.
Add a file pointer parameter to pp_buf so we can send it to varous outputs.
Add more info about the algorithm and keying material to the dump_mode function.

Move the call to it in main after initialization of the algorithm so we can get at this data.
Make return type from crypto function ssize_t to deal with errors from EVP encrypt / decrypt functions.  Deal with these errors in the encrypt function.
Fix weird edge case where the data returned by the crypto function is less than the data read.

The crypto function may buffer some data internally which will mean
we need to write less than we've read momentarily.  Similarly we'll
end up writing more than we've read at some future time as this
buffered data will come out eventually.  This was causing bad
'short write' error messages.
Add a 'decrypt' function.  Force the use of the NULL encryption algorithm for now as AES doesn't work ... yeah ... about that ...