Implement shared credentials across gridscale tools (#136)

[JanLukasGithub]

1. Changes the config path from /gscloud/config.yaml to /gridscale/config.yaml and
2. Changes the config contents from

accounts:
- name: default
  userId: xyz
  token: xyz
  url: https://api.gridscale.io
- name: somthing-else
  userId: xyz
  token: xyz
  url: https://api.gridscale.io

to

projects:
- name: default
  userId: xyz
  token: xyz
  url: https://api.gridscale.io
- name: somthing-else
  userId: xyz
  token: xyz
  url: https://api.gridscale.io

as proposed in #136

Changes the name of --account flag and GRIDSCALE_ACCOUNT environment variable to --project and GRIDSCALE_PROJECT respectively for consistency reasons

There will be no compatibility to GRIDSCALE_ACCOUNT as it wasn't part of the last release, but --account will still be usable, though deprecated and lower priority than --project

The old config path/contents can still be loaded, but the user will be warned of deprecation

gscloud move-config will be introduced. copying and converting the old config to the new one

[nvthongswansea]

@JanLukasGithub this is gonna be a breaking change.

[JanLukasGithub]

@JanLukasGithub this is gonna be a breaking change.

That's why I asked

Should I implement a tool to copy the old config to the new location, if the old but not the new one is present, or something along those lines?

And yes this should only be pulled for the next major release (The issue has milestone v0.12.0)

[nvthongswansea]

@JanLukasGithub this is gonna be a breaking change.

That's why I asked

Should I implement a tool to copy the old config to the new location, if the old but not the new one is present, or something along those lines?

And yes this should only be pulled for the next major release (The issue has milestone v0.12.0)

Yep, a migration will be needed for the new config.

[bkircher]

Looks OK from my side. Wouldn't bother much with automatically moving the old config to the new gridscale/config.yaml path, but it's fine. What is missing is a good Changelog entry. So that users can immediately see the change and act accordingly. Updating the binary is an active step anyway.

[JanLukasGithub]

Should I put the changelog as v0.11.1 or as v0.12.0? I think v0.12.0 is more adequate for the amount and impact of the changes

[bkircher]

@JanLukasGithub Agree, v0.12.0 makes more sense.

[bkircher]

Looks great! Everything looks ready from my side

[JanLukasGithub]

Rebased

[bkircher]

Picked into master branch