Remove confusion in pipelines CodePipeline construct addStage

### Describe the feature

As per [this CDK discussion](https://github.com/aws/aws-cdk/discussions/23888) it is still very confusing for a lot of people that `CodePipeline.addStage()` is not to add a stage in a pipeline but to deploy an application Stack.
There is a workaround using `CodePipeline.addWave()` but this is also confusing since a Wave is normally for parallel deployment in different regions.
These methods should be changed and the `CodePipeline.addStage()` method reserved to, well, add a Stage.

### Use Case

This would help avoid confusion when developing and also reading the code. This feels like unnecessary cognitive load.

### Proposed Solution

The request is as follow:

- Rename `CodePipeline.addStage()` to something like `CodePipeline.addStackDeploymentStage()` or `CodePipeline.deployStack()`
- Add a `CodePipeline.addStage()` which does what the name suggests like aws_codepipeline `Pipeline.addStage()`
- Keep `addWave()` for deploying an application Stack in parallel `public addWave(stages: Stage[], options?: WaveOptions): Wave`

### Other Information

With the above proposed solution, this would however mean that `CodePipeline.addStage()` would behave differently, so people updating their CDK version without updating their code would face issues.

### Acknowledgements

- [ ] I may be able to implement this feature request
- [x] This feature might incur a breaking change

### CDK version used

2.176.0

### Environment details (OS name and version, etc.)

Windows 11

Start with the CodePipeline.addStage() and CodePipeline.addWave() entry points described in the issue, then read the linked CDK discussion and the aws_codepipeline Pipeline.addStage() behavior. Clarify the intended API boundaries and breaking-change migration expectations before locating the construct implementation and its tests. Done means the naming and behavior are unambiguous and covered by the relevant tests.

Written by the indexing model from the issue text.