Replace fs.ReadStream-centric handling with more generic PathReference

[Acconut]

In all current tus-js-client versions, the only way to upload a file on disk in Node.js without loading the entire content into a Buffer is to create an fs.ReadStream and pass it to the Upload constructor. While this might make sense in the beginning, it's actually pretty useless since tus-js-client doesn't use the stream at all to read the file. Instead, it inspects the fs.ReadStream's path property and uses it when opening new fs.ReadStreams for each PATCH request.

This allows tus-js-client to effortlessly seek to previous positions without buffering when the upload is interrupted and has to be resumed. However, requiring our users to first create an fs.ReadStream, which then basically thrown away by tus-js-client is not a good approach.

Hence, this PR changes how files can be uploaded in Node.js. Instead of testing specifically for fs.ReadStream, tus-js-client will now accept a more generic object that matches a PathReference interface, which is basically just an object with a path property and optional start/end positions (see lib/options.ts). The interface has been designed to match fs.ReadStream, so existing integrations with tus-js-client won't break due to this PR.

However, the new interface allows users to also upload files by just giving tus-js-client the path:

import { Upload } from 'tus-js-client'

const file = { path: 'path/to/my/file.txt' }

const options = {
  endpoint: 'https://tusd.tusdemo.net/files/',
}

const upload = new Upload(file, options)
upload.start()