Applying config

Following the question by @tapadipti
> Where will the list of all possible stages be defined? Or, is the user free to provide free text stage names?

There is a config file called .gto that user commits to the repo. In it, he can specify list of allowed stages. GTO has API to provide that: gto.api.stages() will return what user has specified, e.g.: [prod, stage]. If he didn’t specify anything, API will return empty list [] - which means any Stages are allowed.

One related question is this: now in CLI we read that config from workspace. E.g. if you’re on HEAD, then we read it from HEAD. I guess it does make sense to read it from the commit we are creating the actual promotion in. E.g. if I create git tag that reference commit abc1234 - should I read config from there?

I think reading from current workspace is easier and has more useful application. E.g. if I want to add something the allowed list, I want to be able to promote to that env even from previous commits, as opposed to limiting myself with types I specified in that commit.

The other question is: can I have a scenario when in different HEADS I want to have different STAGE_ALLOWED lists? E.g. in `master` I want to have `prod`, in `dev` I want to have `dev`. Then to promote to `prod` I would need to merge my model from `dev` to `prod` - and then promote.

Another thought - can I somehow restrict creating tags in `master` only? E.g. create TYPE_ALLOWED=[prod, dev] in `master`, but disallow promotion in other branches with something like `PROMOTION_DISALLOWED=True`?

Or should it be `TYPE_ALLOWED=[]` and `gto stages` should return different things when `TYPE_ALLOWED=None` and `TYPE_ALLOWED=[]`?