aws-cdk-lib/aws-batch: grantSubmitJob option to allow submission of any job revision

### Describe the feature

When granting permission to submit a job on a particular queue to a grantee, it would be very helpful to either default to granting permission to submit any job revision, or to have an option which allows submission of any job revision, or both. For example,

```ts

const myJob = new batch.EcsJobDefinition(this, 'MyJob', {...});
const myQueue = new batch.JobQueue(this, 'MyQueue', {...});

myJob.grantSubmitJob(myGrantee, myQueue, {allowedRevisions: [1,2,3]});
// or
myJob.grantSubmitJob(myGrantee, myQueue, {allowAllRevisions: true});
```

Naturally, these illustrate the feature for an explicit option for allowing submission of any revision. The interface would not change if the underlying permissions were simply broadened by default, but this might be undesirable for some users.

### Use Case

When granting permission to submit a job on a particular queue to a grantee, the current implementation grants permission only to the specific version of the job that is currently being defined by the CDK. For example, if I have a CDK stack containing

```ts

const myJob = new batch.EcsJobDefinition(this, 'MyJob', {...});
const myQueue = new batch.JobQueue(this, 'MyQueue', {...});

myJob.grantSubmitJob(myGrantee, myQueue);
```

then the generated policy item looks like

```json
{
"Action": "batch:SubmitJob",
"Resource": [
"arn:aws:batch:us-east-1:000000000000:job-queue/MyQueue",
"arn:aws:batch:us-east-1:000000000000:job-definition/MyJob:1"
],
"Effect": "Allow"
}
```

This means that if the grantee attempts to submit a job using

```ts
new SubmitJobCommand({
jobDefinition: 'MyJob',
...
});
```

the submission will fail due to insufficient permissions. This is somewhat unintuitive, as I expect to be able to submit a job without specifying a revision name within my app, given that the revision mechanism is abstracted away within the CDK deployment process.

### Proposed Solution

This can be achieved through simple tweaking of the `batch.EcsJobDefinition.grantSubmitJob` method. As an example, my current workaround is to simply replace the call with

```ts
iam.Grant.addToPrincipal({
actions: ['batch:SubmitJob'],
grantee: myGrantee,
resourceArns: [
`arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}`,
`arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}:*`,
jobQueue.jobQueueArn
],
});
```

### Other Information

_No response_

### Acknowledgements

- [x] I may be able to implement this feature request
- [] This feature might incur a breaking change (although if the underlying default permission is changed, this might be considered breaking in terms of security posture for some users)

### CDK version used

2.185.0

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

MacOS 15.3

Start at EcsJobDefinition.grantSubmitJob and inspect how its current policy resources produce the revision-specific example in the issue. Compare the proposed allowedRevisions and allowAllRevisions behaviors, including the revisionless job-definition ARN. Done means the chosen API behavior is defined and covered for both revision-specific and any-revision submissions.

Written by the indexing model from the issue text.