RFC: Clearly separate APIs for public use RFC2021-05

[iJungleboy]

While documenting I stumbled across an architecture issue which I believe will haunt us in future if we don't address them early.

To explain, I'll demonstrate this on the ConnectionStringField class documented here: http://docs.oqtane.me/api/Oqtane.Models.ConnectionStringField.html

Basically it's purpose (AFAIK) is to help in very specific Oqtane-internal dialogs to configure Database settings. As of now, there is no relevant reason why Module Developers should access this. It's actually important that they don't ever use this, since some day you may make it more generic and have to rename (like to GenericInputField) or modify it and not worry about external effects.

So my point is there should be a clear distinction between

1. APIs for public use, which developers creating solutions on Oqtane should use. These must of course remain very stable and be well documented.
2. APIs for the building of Oqtane and Oqtane-internal dialogs and processes which are expected to only ever be referenced in the Oqtane solution, so we can freely rename them, modify them etc. as we see fit, without worrying about side effects.

There are a few ways to do this, including

1. Adding Attributes like the [PrivateApi] and hiding these in documentation
2. Makeing them internal and configuring the assembly so internal models are available on the core Oqtane projects, basically making internal a public inside Oqtane only
3. Using different namespaces

Your thoughts.