Test fread return value

Ignoring the fread return value triggers warnings at high warning levels. It's also a bad idea in general to assume that reads always succeed, though admittedly fewer things could go wrong when reading from a kernel device. I still much prefer that all code build clean at the strictest warning levels, however.

Discussion:

This patch attempts to be minimal by simply asserting that all bytes requested were read and perhaps should be revised before merging. For embedded work it would be better to report an error condition (maybe after a re-try?) rather than assert()-ing (this will likely be necessary for our project, as crashing would be unacceptable), but that would be a more invasive change and might require a cascade of changes to the calling functions to report errors as well. I would prefer more extensive error checking/reporting in general, but I don't know how that fits in with your vision for the library.

Are you willing to consider a larger patch to add some error reporting up the call tree? If so, do you have a library policy for how errors are reported? I see that generate_k_rfc6979() returns an error code, so I suspect you prefer that style to adding an error code parameter when the function does not already have a return value.

Minor changes:

size_t is the right type for an array count. I also added VIM backup files and Windows executables to .gitignore.