Fix #311, Free (close) FileDescriptor resource to avoid leak

[thnkslprpt]

Checklist*

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to [email protected] and copied [email protected].

Describe the contribution
Fixes #311
Added additional close() for FileDescriptor which was missing before the end of the function.

Testing performed
GitHub CI actions (incl. Build + Run, Unit Tests etc.) all passing successfully.

Expected behavior changes
FileDescriptor freed (closed) before going out of scope, avoiding slight resource leak.

Contributor Info
Avi @thnkslprpt

[jphickey]

I wasn't sure about this one, but based on this comment it should be OK: https://stackoverflow.com/questions/17490033/do-i-need-to-keep-a-file-open-after-calling-mmap-on-it

What Coverity doesn't know (and why this was reported as a "leak") is that this is a setup function that is only called once at start-up, and the file is supposed to remain available for the entire duration of the CFE instance, until the parent process exits - at which time the filehandle is closed automatically. So while not ideal, it was not an actual resource leak.

We should confirm, however, that the simulated EEPROM here still works after closing the file handle - that is, read/write of the mapped memory still works and updates the file on disk. The man page of mmap says its supposed to, but I would recommend confirming that it actually does.

[thnkslprpt]

Closing this PR as per comments in #311 (comment)