Refactor the custom resource provider as proposed in #9

[mindstorms6]

This change makes it such that each custom resource is split into 2 parts

The "resource provider" and instances of the custom resource, that refer to a given provider.

This also for the Lambda backed provider adds the ability to add custom permissions :)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[eladb]

I think this is getting closer in terms of "soundness", but I think it's important that adding an instance of the custom resource to one's stack will look and feel like any other construct. We want to encapsulate the fact that this is a custom resource, so that users won't be able to tell.

The reasoning is that 3rd party SaaS providers should be able to vend construct libraries that will expose constructs that represent their SaaS and should behave exactly the same as AWS constructs.

This means that any API we are designing for the classes that support the declaration of custom resources should eventually allow resource authors to provide an API that looks like this:

new Fabulous(this, 'MyFabulous', { /* props */ });

Like any other construct!

To me, this technically means that the singleton lambda must be somehow "hidden" behind this construct.

[eladb]

@mindstorms6, Seems like you are blocked on the ability to add permissions to a lambda upon creation, which is something that I totally think we can add to LambdaProps itself. So feel free to submit a PR that does that and we can exhaust this important discussion about custom resources without blocking you.

[eladb]

Deprecated by #35