Using `indirect` modifier for `struct` properties

[Joe_Groff]

@allevato

However, property wrappers now provide an elegant solution to this without requiring changes to the language/compiler. While I do think there's the slight disadvantage that the difference between indirect case and @Indirect for a property could be confusing to new users at first, I think that's outweighed by the principle that (IMO) we should prefer library-based solutions over compiler-based solutions whenever possible.

I can see a few reasons why we would prefer a language-supported indirect modifier over a property wrapper solution:

• First, as you noted, indirect already exists for enums.
• A wrapper-based solution would necessitate use of a class as the backing store, when it would be more efficient to use non-class heap allocations like we do for closures and indirect enum payloads.
• A wrapper would necessitate a separate heap allocation for every indirect property. In the majority of cases, it would be better for there to be a single indirect buffer per value holding all its indirect properties.
• Eventually, it may make sense for the compiler to do automatic layout optimizations, so that structs which are very large or which have multiple refcounted properties automatically indirect some or all of their fields. Having this optimization not rely on the existence of a library type would be nice.
• Property wrappers interact with Codable and reflection in various ways, because the underlying storage is formally of the wrapper type. indirect enum cases, on the other hand, are mostly transparent to those APIs, and ideally, indirect struct fields would be as well.