C library: provide implementations of fopen64, freopen64

[tautschnig]

Some implementations map fopen and freopen, respectively, to the above when large-file support is enabled. To us, large-file support makes no difference, so just use a single implementation for both cases.

Will eventually fix Debian bug report 1069438.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[kroening]

I would have made fopen64 call fopen, but ok.

[tautschnig]

I would have made fopen64 call fopen, but ok.

I have intentionally not done this: fopen might be renamed to fopen64 via asm renaming or a macro. We would then end up with recursion in fopen64.

[kroening]

I would have made fopen64 call fopen, but ok.

I have intentionally not done this: fopen might be renamed to fopen64 via asm renaming or a macro. We would then end up with recursion in fopen64.

Ok, that probably means that we will rename everything to some unique name eventually, say cprover_fopen etc.