Provide an initializer at the requested access level or fail

[gohanlon]

Continuing the theme of #7:

@MemberwiseInit has traditionally mirrored Swift's memberwise initializer, adapting to the access levels of struct properties. This adapting behavior is necessary for Swift's initializer, which operates without explicit developer intent.

However, when a developer annotates a struct with @MemberwiseInit(.public), their intention is clear: they expect a public initializer. If the struct includes a private property, MemberwiseInit, as it stands, provides a non-public initializer. This outcome, often discovered later and indirectly, is surprising.

@MemberwiseInit should instead fail immediately in such cases, offering immediate, actionable diagnostics. For example, suggesting the annotation of properties with @Init(.public) or recommending access level adjustments.

With this change:

• MemberwiseInit better aligns with the explicit and intentional practices preferred in Swift.
• Unburdened from the nuance and complexity of Swift's memberwise initializer, README will become considerably shorter.
• Usage will become more obvious and incrementally learnable through experience applying the macro and responding to diagnostics—"reading the manual" becomes much less necessary.
• MemberwiseInit is still safe by default.

While residing in a somewhat grey area, I consider this a non-breaking change:

• It aligns with the logical use of MemberwiseInit: using @MemberwiseInit(.public) while intending a non-public initializer is unlikely to begin with. Furthermore, were your intent to add an internal or private initializer, you wouldn't have much reason to reach for MemberwiseInit over Swift's memberwise initializer.
• Existing code using @MemberwiseInit(.public) but not requiring a public initializer likely indicates a mistake, which this change proactively corrects.

[davdroman]

Perfect! I think this is the right design philosophy to adopt 👌