Default initializable init properties shouldn't prevent default
init synthesis and such properties without anything to initialize
should be considered by it.
Adjust DI to treat init accessor properties that have only 'accesses'
or no restrictions as if they are stored properties, this means that
if such property doesn't have a default initializer users would have
to reference it explicitly in their custom initializers.
We also need to suppress default init synthesis for such cases which
would be done in a followup commit.
Resolves: rdar://113401979
If stored property is covered by one or more init accessor property,
it's default initializable when at least one of the init accessor
properties has default value.
Per the clarification during the review thread, all properties with
init accessors (including those that do not initialize any underlying
storage) are part of the memberwise initializer.
Skip stored properties that are initialized via init accessors and
emit parameters/initializations in field order which allows us to
cover more use-cases.
If some property is initializable by one than one init accessor
let's not sythesize a memberwise initializer in that case because
it's ambiguous what is the best init accessor to use.
If init accessor initialize the same properties, let's emit them
in sequence and emit `destroy_addr` in-between to make sure that
there is no double initialization.
