Comments on tagged strings

Re. https://github.com/dart-lang/language/blob/master/working/tagged-strings/feature-specification.md

* Implicitly appending "StringLiteral" to the name is a hack. Not sure what is better, but I'd go with
```dart
extension WhatNot on String {
R operator foo(List s, List i) { ... }
}
```
to declare a prefix operator on strings instead. Then the operation is not looking up things in the lexical scope
at all, but on the string. Not hacking the lexical scope is better.
* Grammar needs to say that `identifier` cannot be `r`, which is taken for raw strings.
* The grammar only allows a *single* identifier as the tag. It should at least be qualified, so you can use a prefixed import (if not going the extension operator way, which is resolved wrt. the string, not the scope).
* Possibly even two-dotted qualified name, so you can refer to a static function with a prefix.
* (Alternatively, allow any expression to be followed by a string literal, without name manglig.)
* The interpolated expressions should be typed, not just as `Object?`. That's too JavaScript-y.
* A string tag of type `R Function(List, List)` should only allow expressions with type `Y` in interpolations.
* A generic `R Function(List, List)` tag should infer the `X` from the interpolation expressions (and `R` can then depend on it).
* Not sure thunking interpolations is *worth* it all of the time. Maybe you can opt in to it.
* If your tag has type `R Function(List, List` for some type `T`, then an interpolation expression of type `T` is auto-thunked for you (and an interpolation expression of type `T Function()` is not).
* Or maybe you have to provide a syntactic marker, like using ``$`expression` `` instead of `${expression}` to have it thunked.
* It's also dangerous to move code into a different function for a number of reasons, current and potential future:
* As you noticed, it doesn't play well with `async`. There was a reason we stopped desugaring into lambda expressions in the spec, it was just wrong most of the time after introducing `async`.
* We don't know if it will interact similary with future features. It's a design smell to move code from the context where it's written.
* In general, I think I'd just *not* do implicit thunking, the interpolation expressions are always evaluated eagerly, and the second parameter has type `List`, not `List`.
* About `async`.
* I think not making interpolations thunked at all by default makes it trivial. So do that.
* If not, it's going to need a truck-load of heuristics to get it right in most of the cases.
* If you have to *ask* for thunked expressions (in any way), and you do so inside an `async` function, then:
* either your second parameter accepts a future, `List Function()>` or `List Function()>`, and then the function is thunked using an `async` method if necessary (has type `T`, or has type `Future` and contains `await`),
* Or it doesn't, and then the expressions are thunked using a non-async function, which makes it an error to contain `await`.

Start with working/tagged-strings/feature-specification.md and review the existing tagged-strings proposal alongside this issue's unresolved alternatives. The work is not ready for implementation until the design settles the tag grammar, interpolation typing and thunking behavior, including async interactions; done would be a consistent specification update reflecting that decision.

Written by the indexing model from the issue text.