Clearly communicate the supported operations of an AccountKey

[Supereg]

Problem

Currently, an AccountKey implementation must always provide DataDisplay and DataEntry views and an implementation has little to know control to specify if it is readOnly, writeOnly (e.g. only supply a verification code at signup) or readWrite (any other possibilities?).
For AccountKey of category credential there is, due to the current implementation, a workaround to implement writeOnly account values (see here #7 (comment)).
Status properties (like emailVerified) reported from account services also always need to implement a DataEntry view.

Solution

This issue propose a potential solution to this problem by allow to declare DataDisplay and DataEntry types as EmptyViews and adding respective documentation explaining the impact of such. The above-illustrated use cases would be resolved like the following:

• Read-Only account values are declared by setting an EmptyView to the DataEntry type. Therefore, the never show up in the signup view (independent of their requirement level configured by the user) and might show up in the Account Overview if the user decides to configure the AccountKey as supported.
• Write-Only account values are declared by setting an EmptyView to the DataDisplay type. This would require additional code to exclude any write-only account values from the AccountOverview view and only render these account values in the SignupView if configured by the user.

Additional context

It might make sense to add @available(*, deprecated, message: "...") annotations to the ConfiguredAccountKey methods if ...

• ... you want to configure a read-only account value as required or collected, as they might only be configured as supported.
• ... you want to configure a write-only account value as supported as they would never show up in the AccountOverview.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines