Support specifying confusing instance names

[DifferentialOrange]

1. Application name as instance name

Now we don't support instance names which coincide with application names:

cat ./instances.yml 
---
myapp.myapp:
  advertise_uri: localhost:3301
  http_port: 8081

cartridge start -d
   • myapp.myapp... OK

cartridge status
   • myapp.myapp: RUNNING

cartridge status myapp
   ⨯ Application name is specified. Please, specify instance name(s)

2. Instance name with dots

The reason is this code in GetInstancesFromArgs method: https://github.com/tarantool/cartridge-cli/blob/80f0f6374c320e36806e247c406a49665fc41e57/cli/common/utils.go#L385-L387

We also do not support instance names with dots:

cat ./instances.yml 
---
myapp.my.app:
  advertise_uri: localhost:3301
  http_port: 8081

cartridge start -d
   • myapp.my.app... OK

cartridge status
   • myapp.my.app: RUNNING

cartridge status my.app
   ⨯ [APP_NAME].INSTANCE_NAME is specified. Please, specify instance name(s)

The reason is this code in GetInstancesFromArgs method: https://github.com/tarantool/cartridge-cli/blob/80f0f6374c320e36806e247c406a49665fc41e57/cli/common/utils.go#L389-L393

3. Specifying an instance name multiple times

GetInstancesFromArgs also doesn't allow to specify an instance multiple times: https://github.com/tarantool/cartridge-cli/blob/80f0f6374c320e36806e247c406a49665fc41e57/cli/common/utils.go#L400-L402

---

Proposed solution

The reason of the issues 1 and 2 is the desire to help a user if they specified application_name or application_name.instance_name instead of instance_name. It results in inability to use some instance names in some commands which are (likely) supported by any other command. We need to

1. allow a user to use such names
2. after verifying that any other command is fine with that.

To preserve existing helpful error messages in case user really specified application_name or application_name.instance_name instead of instance_name (which is rather often), we'll need to rework our approach. If user had provided an invalid info, the command should fail. And if the command had failed,

3. we additionally check if they had specified application_name or application_name.instance_name instead of instance_name and, if they are, add this info to error message.

Regarding issue 3, we may simply

4. start to skip duplicate names instead of throwing an error,

but, since there are no such request from customers yet, we may ignore this one for now.

Based on https://jira.vk.team/browse/TNT-765