[ECR] [Feature Request]: ECR token validity control and password based authentication.

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
What do you want us to build?

Users would like to control ECR token validity. Currently GetAuthorizationToken API or get-login-password do not allow to specify token validity and by default it dispense 12 hour validity token. Users would like to have better control over token validity while requesting it. Provide long validity or password based authentication for ECR repo.

**Which service(s) is this request for?**
ECR

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

In some use-case where users would like to provide tokens to the CICD pipeline OR Developer machines to have token issued for specific validity :
- long valid token for Developer machines or jump box for specific actions for defined durations
- very short duration which is just sufficient to finish pipeline execution)
- Also yet another ask is to have possibility to have password based authentication for ECR repo.

**Are you currently working around this issue?**
How are you currently solving this problem?
Users have to use IAM role to renew token every 12 hours. Also use ECR authentication helper to review token automatically.

**Additional context**
Anything else we should know?

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start by reviewing the requested ECR GetAuthorizationToken and get-login-password behavior in this issue. Separate the token-validity and password-authentication requests, then identify the AWS service/API owners and constraints. Done would require an agreed product design and documented support for the requested authentication controls.

Written by the indexing model from the issue text.