Support resources as proxies, and adoption/abdication

One of the custom resource patterns we use at iRobot is the concept of a _proxy resource._ This is a custom resource that allows you represent a resource in a CloudFormation template, like a DynamoDB table, including all of the return values that a native [AWS::DynamoDB::Table](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html#aws-resource-dynamodb-table-return-values) has, taking the table name (or ARN) as its only parameter.

These proxy resources enable two things: first, a reduction in the number of template parameters, since one ARN can then be sufficient to produce multiple resource attributes that may be needed. But more importantly, it lets the template express the intended infrastructure graph more completely in the template.

With proxies, a further useful feature becomes possible: _adoption_ and _abdiction._ Adoption is where a the resource represented by a proxy resource transitions to being owned by the CloudFormation stack it is in. Abdication is the opposite, where a resource created by a stack becomes a proxy resource, giving up control over it and allowing it to be managed independently (potentially by being adopted into a different stack). Everyone's had times where the way one's infrastructure has been carved out into stacks is later found to be suboptimal, but once there's data stored in it, there's nothing you can do about it. Adoption/abdication would change that.

The issue contains a feature proposal but names no repository files, tests, or implementation entry point. Start by clarifying the proxy-resource, adoption, and abdication requirements; done would require CloudFormation support for the described lifecycle transitions.

Written by the indexing model from the issue text.