Addressed some bugs introduced in the `sha256_file()` function

These bugs were introduced in 43f759db4751655ecc0f3d995ccbae9d6d5ff4e3

There were a few issues:

The existing code didn't compile because the code used both fileLength and fileLen to mean the same thing. This PR includes the fix proposed by @Zalamar in usnistgov/SP800-90B_EntropyAssessment#202
const was used incorrectly; buffer was declared to be a pointer to a constant region, which then was changed. In this case, the pointer is fixed, but the value being pointed to is changed.
A memory leak is introduced; the code used malloc to allocate memory, but the free call isn't ever used (or available, without adding additional headers) and the buffer pointer is not available outside this function. This PR uses the C++ new/delete operators instead.
The buffer array was larger than it needed to be. (This buffer is not a c string, so there is no trailing null character).
Errors were not consistently flagged. (Several errors resulted in a return code of 0, indicating success...)
There was no error checking on the file read.
There was a double free due to two different fclose() calls.
Old code was left in place. Version tracking generally removes the need for this sort of thing. I removed these block comments.
There was no newline present on the last line of the file.

I propose that future changes be compiled and run on data at least once prior to checking in the code, particularly when the code is going into the master branch.

Resolves usnistgov/SP800-90B_EntropyAssessment#203 Resolves usnistgov/SP800-90B_EntropyAssessment#205 Resolves usnistgov/SP800-90B_EntropyAssessment#206 Resolves usnistgov/SP800-90B_EntropyAssessment#210 Resolves usnistgov/SP800-90B_EntropyAssessment#211

usnistgov / SP800-90B_EntropyAssessment

Addressed some bugs introduced in the `sha256_file()` function #204