Add support to data-driven fixes to handle cases where the return type has changed

[bwilkerson]

The data-driven fixes support doesn't currently support the case where the return type of a member has changed.

For example, consider a change from

String get value;

to

int get value;

What's needed here is a way to specify how to update the invocation sites so that they aren't broken.

It would be easy to allow a prefix and suffix pair that would just contain the code that needs to surround the invocation. You could imagine, in this example, specifying an empty prefix and a suffix of .toString(). Then a typical invocation site, such as

takesAString(myObject.value);

could be converted to

takesAString(myObject.value.toString());

However, a guiding design principle of the data-driven fixes support is to allow the change to be expressed in a semantic, rather than syntactic, way so that the tool can adapt to differing references to the member. For example, it should be possible for the tool to leave

print(myObject.value);

unchanged, because print takes an argument of type Object and the new type is already compatible with it.

And it would be nice if a use such as

takesAnInt(int.parse(myObject.value));

could be converted to

takesAnInt(myObject.value);

because it could tell that the new type doesn't need to be converted. (Though that's probably too big an ask.)

There are also cases where the type might be the same, but the value needs to be "adjusted" in some way. Consider flutter/flutter#162609 as one example, where a getter was returning an int, but the new getter is returning a different int that needs to be manipulated to get an equivalent value. (Specifically, color.red needs to become (color.r * 255.0).round() & 0xff This would be harder to express in a semantic way, so it's tempting to say that we should just allow a syntactic representation, but even this really needs some semantic context so that we know, for example, whether to enclose the expression in parentheses because of operator precedence.

We need to do some design work to figure out what information we need in order to support this well, but hopefully the above helps define the scope of the feature.