Support gzipped and TCX tracks

[c-harding]

Following the new Strava GDPR update (#17), the export now includes the tracks in their original format. These are sometimes gzipped, and can be either GPX or TCX (common for MapMyRide transfer). This PR adds support for such files.

Minor changes:

• Include instructions for exporting from Strava with new system.
• Version bump for leaflet, babel, webpack and others.
• Use webpack-serve rather than webpack-dev-server, as the latter is in maintenance-only mode.
• Add npm run scripts for linting, building and serving, so that webpack, eslint and webpack-serve do not need to be installed globally.
• Export bundle.js to root, rather than dist/, as it was copied back immediately in the build script. This way it can be used live with the dev server.

[c-harding]

This feels rather more convoluted than before, because:

• Reading the contents of an image as text doesn't make sense, so handling images should be done before unzipping.
• Gzipped files have a double extension, so file.name.split('.').pop().toLowerCase() would not contain the information on the underlying file type.
• handleTrack should not have to deal with the type of the file.
• handleFile can't be called recursively, because wrapping the unzipped result back into a file object would be hard and inefficient.

Alternatively, handleFile could be rewritten to take the extension, as before, and either

• call handleImage,
• call handleTextFile with the contents of the unzipped file, as well as the remaining filename, or
• call handleTextFile with the contents of the text file, as well as the remaining filename.

[c-harding]

Is it worth storing whether the file is a TCX or a GPX file, or is it enough to look at what the root element within it is (src/track.js:21)?

[erik]

I think your implementation works fine for this 👍

[erik]

This is great! Thank you for putting in the effort to get the new format working.

Works well for me locally so far.

[erik]

I think your implementation works fine for this 👍