cdk-assets: extensibility

### Description
Before a stack is deployed, the `provisioner` will prepare all of the `assets` required by the stack. The types of assets currently supported are `zip`, `file`, `container-image`.

There are cases where other asset types would be useful, like existing container images (use case below). Leaving aside that CloudFormation can already handle that (use case below), this seems like a perfect use case for Plugin support.

#### Proposal
Allow plugins to contribute new asset types for preprocessing before stack deployment.

### Use Case
I am using an internal container registry as the master repository for all of my Docker containers (used across all AWS Accounts). During the build, we already have the credentials for the internal (non-aws hosted) container registry and the URI to the particular container.

I then create two stacks, the first of which contains the ECS Cluster and Repository definitions. The second stack creates the task definition and requires the cluster and Repository as input parameters.

Before the second stack deploys, it would be great if we could issue some type of `docker push` command since the URI and repository are known at that time. I know this could be done with CloudFormation using SecretsManager. But push the container to the repository before the stack deploys feels a little cleaner to me...

### Proposed Solution
Allow plugins to contribute new asset types.

### Other
* [x] :wave: I may be able to implement this feature request
* [x] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

Start by tracing the cdk-assets provisioner and how it handles the existing zip, file, and container-image asset types. Define how plugins contribute additional asset types and how those types are preprocessed before stack deployment; done means a plugin can register and process a new asset type without breaking existing assets.

Written by the indexing model from the issue text.