Support user-defined implicit conversions via ImplicitAs

[zygoloid]

Support is added for all of the non-type expression contexts where we currently accept built-in conversions, such as reordering the fields in a struct.

[jonmeow]

I'm happy to do another round before end of day, but ping me directly since I'm probably vanishing for a couple weeks around 4pm.

[jonmeow]

Where you're adding setters, is there anything this can do relative to checking type checking of rhs_ or rhs that would help enforce the "Can only"? Maybe it would make sense to do something like "set_desugared_rhs" which could only be called once, and a desugared_rhs getter that returns desugared_rhs if set, rhs otherwise?

Note, I'm wondering about this mainly in the larger context of adding setters. This could go a step further with a templated type, e.g.:

template <typename T>
class Desugarable {
 public:
  Desugarable(Nonnull<T*> original) : original_ {}
  // Should be called at most once by type-checking.
  void set_desugared(Nonnull<T*> desugared) { CARBON_CHECK(!desugarded_); desugared_ = desugarded; }

  // Would it even work to have the non-const version CARBON_CHECK if desugared_ is already set, in order to prevent accidents?
  auto original() -> T& { return original_; }
  auto original() const -> const T& { return original_; }
  auto desugared() const -> const T& { return desugared_ ? *desugarded_ : original_; }

 private:
  Nonnull<T*> original_;
  std::optional<Nonnull<T*>> desugarded_;
};

Then maybe something like this becomes:

auto rhs() const -> const Desugurable<Expression>& { return rhs_; }
auto rhs() -> Desugurable<Expression>& { return rhs_; }
Desugarable<Expression> rhs_;

However, that's a much higher code delta, especially because it affects interpreter call sites. Thoughts?

[zygoloid]

I think there is probably a better direction here, but I think it's likely to take a bit of discussion to hammer out the best approach. Do you want this addressed before this change lands, or can this be deferred to a later refactoring?

[jonmeow]

I think it's probably reasonable to defer to a later refactoring, that was part of my concern over size of the delta.

[jonmeow]

FWIW, I'd typically suggest TODO instead of FIXME for anything that's expected to outlast the given PR, because that's what the style guide says to use:
https://google.github.io/styleguide/cppguide.html#TODO_Comments

I haven't commented much on this because I'm not sure how much you're using FIXME to indicate things you intend to fix either before merging or quickly after, but this sounds like it's very much "eventually".

[zygoloid]

Done.

[jonmeow]

Just to note, I'm doing more cleanup of this in #1282

[jonmeow]

Should probably wrap these to 80 char columns

[zygoloid]

Done, though I somewhat arbitrarily invented some wrapping and indent rules. I assume we'll eventually have a tool to automate this, and we'll run it over all of our existing Carbon code once it exists, so I guess the precise formatting choices right now don't matter too much.

[jonmeow]

Yeah, arbitrary rules is kind of what I expected.

[jonmeow]

Approving -- as noted, I think it's fine to refactor the desugaring further in another PR.