portable(s) are not actually portable

I didn't notice earlier since I try to go for fresh deploys, but that's a major dealbreaker for a '''portable'''. Users expected it to work like any https://portableapps.com/ and I was surprised it didn't. #2112 made me investigate again.

Windows zip

https://github.com/mattermost/desktop/releases/download/v5.0.4/mattermost-desktop-5.0.4-win-x64.zip

Creates a folder in %appdata%.

Still better than an installer, but not portable by any means. Users were surprised why they needed to enter server details all of a sudden, after moving the folder.

Linux binary

https://github.com/mattermost/desktop/releases/download/v5.0.4/mattermost-desktop-5.0.4-linux-x64.tar.gz

Creates one in ~/.config which isn't great, but expected on Linux. There's not a whole lot of typical user awareness (of any kind) on desktop Linux yet. Copy, paste, done. Still would be nice if a plain binary build would stick to a relative ./userdata/ until told otherwise.

At the very least, people need to be made aware of the Windows zip not actually being a portable as you'd expect by downloading a presumably self-contained zip. Almost every ordinary Windows user knows the 'self contained portable' concept and this is unexpected.

How about a default of ./userdata/ on both platforms, and a CLI parameter --datadir xyz to choose wherever?

Start by reproducing the Windows zip and Linux tarball behavior described in the issue, checking where each build stores its user data. Trace the desktop application's data-directory and CLI argument entry points, then verify that a relative ./userdata/ default and --datadir xyz work consistently on both platforms.