Refactor package structure

[Supereg]

Problem

Currently, SpeziAccount houses a lot of components that are not specific to SpeziAccount and might be reused across other Spezi packages. Further, all API surfaces are currently exposed within a single target.

Solution

There might be Views or Infrastructure that either can

1. ... be exposed as a separate target or ...
2. ... be move to more general Spezi Packages (like Spezi or SpeziViews).

The following is a non-exhaustive list of components that can be moved out of SpeziAccount:

• Validation: SpeziAccount currently ships with a fully customizable and fully abstract validation infrastructure. This could be moved into an entirely new Spezi package or into SpeziViews. This includes views like the ValidationResultsView and the VerifiableTextField.

Further, one could split up SpeziAccount into multiple targets. A potential distribution could look as follows:

• Separating all the Mock Account Services into a separate target (Refer to this discussion about the implications of this change https://github.com/StanfordSpezi/SpeziAccount/pull/7#discussion_r1314246737).
• Separating interfaces that are used by users of SpeziAccount from the API surface used by Account Service implementors.

Particularly one could structure it as follows:

1. AccountService (everything you need to build an account service)
2. Mock Account Service (depends on Account Service)
3. Account Module (only @_implementationOnly imports Mock Account for the previews, and imports AccountService while only exposing (not sure if @_implementationOnly would work there, otherwise we just normally import it which only results into a few types being exposed)

Additional context

No response

Code of Conduct

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