review / refactor python file object vs OS-level file handle usage

[ThomasWaldmann]

for reading the backup source files, borg master branch tries to work based on an open file as much as possible (not working with file names to avoid race conditions). often the api has the file name / path also for better logging or debugging though.

an open file can be represented in 2 ways:

• as a python file object (resulting from python's open() function, useful for most python file api calls)
• as a OS-level file descriptor (int), either from os.open() or f.fileno(), needed if we call OS functions (either os.xxx in Python or C functions via Cython wrappers).

borg functions have 2 different signature styles:

• func(path) - path being either str/bytes for a real path or an int or a file object - this is a bit messy.
• func(path, fd=None) - path being str/bytes and fd (if it is not None) is a python file object (or is it also an OS-level file handle sometimes?). this is a bit cleaner and gives us the filename and the file object inside func, better for debugging / logging.

[ThomasWaldmann]

When reading backup source files, borg calls OsOpen (which is a wrapper around os.open), resulting in a OS-level file handle (int), called fd or dir_fd in the code.