possible restructuring of amplify subdirs?

### Is this feature request related to a new or existing Amplify category?

New category

### Is this related to another service?

_No response_

### Describe the feature you'd like to request

A thought just occurred to me and I thought I'd put it out there. Under the amplify subdir, I see 'backend', '#current-cloud-backend'/, etc..

Problem with this is that it's not clear what the current environment is (e.g. main, alpha, beta, prod, etc.), from simply looking at the subdirs of this amplify directory. Also, this makes it EASY to corrupt the different backends.

Wouldn't it be better to have a different 2nd level directory for each environment? Instead of:

```
amplify/
--> backend
--> '#current-cloud-backend'/

amplify/
--> dev
----> backend
----> '#current-cloud-backend'/
--> alpha
----> backend
----> '#current-cloud-backend'/

```
This way, if I do an 'amplify pull dev', it's pretty much impossible to corrupt the different versions of the backends. Might make the cli api simpler as well, as no need to specify the --appId to guard against the backend corruption, in most cases..

Also, this makes it easy to have a separate team-provider-info.json for each environment.

I haven't really worked with juggling multiple amplify environments in one project yet, but again, it looks to me like the revised directory structure I'm proposing would makes certain things easier with few/no downsides..

Just thought of an even bigger win with this revised directory structure approach. You can have amplify ALWAYS automatically pull in the backend changes for the current environment, with NO risk of corruption. As it is now, the user has to manually pull in backend changes. This should NOT be an optional step. You would generally want the local snapshot of the backend to be in sync with what's on the servers, for each environment.

And, if you have multiple developers, each working on the same amplify app, this eliminates a source of error that stems from a developer having forgotten to do an 'amplify pull'..

Thirdly, this resolves a can of worms situation with version controlling the backend subdirectory. Because the amplify/backend/ directory has a different meaning, depending on the current contextual environment, this introduces the high likelihood of corruption, at the version control level, i.e. inadvertently checking in backend changes for the WRONG environment.

As a rule of thumb, it seems to me that whenever you're version controlling a directory or set of directories, you want it to be lexically obvious, and not context based, depending on what commands the user just recently executed. This latter is fraught with accidents, waiting to happen.

### Describe the solution you'd like

(see feature request section.)

### Describe alternatives you've considered

(not applicable.)

### Additional context

_No response_

### Is this something that you'd be interested in working on?

- [ ] 👋 I may be able to implement this feature request

### Would this feature include a breaking change?

- [x] ⚠️ This feature might incur a breaking change