Remove assumption user ID is 1000

[ukkopahis]

DO NOT MERGE YET

On menu.sh start, store current UID and GID to .env, if they are missing.
Use these to run services that support a custom user setting.

Lines added to .env by menu.sh are e.g.:

# Changing IOTSTACK_UID or IOTSTACK_GID after you have started the stack is not
# supported. File ownerships in the 'volumes'-folder won't automatically update
# to match, resulting in various problems.
IOTSTACK_UID=1000
IOTSTACK_GID=1000

And in templates and services:

services:
  wireguard:
     environment:
     - PUID=${IOTSTACK_UID:?IOTSTACK_UID must be defined in ~/IOTstack/.env}
     - PGID=${IOTSTACK_GID:?IOTSTACK_GID must be defined in ~/IOTstack/.env}

When dropping the ID=1000 assumption, there is only one chance to get this right:

• Starting containers with a given UID may create files in volumes/ using that UID for ownership. Later changing the container to run with a different UID may cause file-permission problems.
• The UID chosen should be the one most convenient for the user, hence the logged in user that runs the menu.

Other small changes:

• add --help options to menu.sh and install.sh
• rephrase installation assumptions, you may preview the changes in my fork: https://ukkopahis.github.io/IOTstack/Basic_setup/#assumptions

Resolves #542, Fixes #183

[Paraphraser]

Err - 100 ? Should that be 1000 ?

I think it's only the commit message above. I couldn't find any 100 in the changed files (but I do have ancient eyeballs).

[ukkopahis]

Err - 100 ? Should that be 1000 ?

I was trying to show what it does on a non-default install. Clarified.

[ukkopahis]

Alternate suggestion (NOT RECOMMENDED)

I think it's better to change this so a .env-file isn't needed nor generated.

Templates would still use the syntax allowing .env-use:

- PUID=${IOTSTACK_UID:?replace with your actual UID}

buildstack_menu.py would identify template environment variable values matching ^\${IOTSTACK_[UG]ID:.*}$ and replace them with the actual UID/GID number of the user running the menu, resulting in a docker-compose.yml with e.g.

- PUID=1000

Resoning

• simpler docker-compose.yml - more beginner friendly
• restoring a backup using an user with a different UID/GID from the ones that took the backup would work better. Restored services would use the UID from backup and the existing docker-compose.yml. New added services would be using the current user's UID.
• preserves manual usage of templates: concatenating (e.g. using cat) templates into your docker-compose.yml and adding a .env-file to define required variables.
• same templates will work in the old menu by using a .env-file (as in the original proposal)

Drawbacks

• more complex menu implementation needed
• manual (template concatenation) use and menu-driven use diverge in results (manual is using .env and menu isn't)