Use private keyword instead of doc tag in stdlibs

[Akirathan]

After #9692, the engine now supports private constructors. Let's change all the constructors in our stdlib codebase that use ##PRIVATE doc tag to use the proper private keyword and ensure that they are checked for private access at runtime.

Follow-up of #8836

Let's not do this change with a text / regex / grep replacements. Let's try to make this change more sophisticated and use already existing infrastructure to traverse the IR of all our modules and make the changes in the underlying text buffer. There is org.enso.text.editing.model.TextEdit in the text-buffer project. There is also org.enso.compiler.context.ChangesetBuilder. As part of this issue, investigate how this infrastructure can be used for these kinds of refactorings. Not only it would potentially save time, but it would also be more safe. This refactoring can be implemented as a separate sbt project that depends only on runtime-parser and applies some changes to the sources.

Tasks

Preview Give feedback

1. Investigate using TextEdit, ChangesetBuilder and co. for the refactoring (add new sbt project)

[radeusgd]

Let's change all the constructors in our stdlib codebase that use ##PRIVATE doc tag to use the proper private keyword and ensure that they are checked for private access at runtime.

Currently we are using the PRIVATE keyword as "don't show this in the GUI" tag as well. That means we definitely do not want to change all constructors marked as PRIVATE to be private. In many cases we have constructors that are more 'advanced' or are just not prepared for usage in interactive mode and should be hidden in the GUI, but they are OK to use for users. We probably will want to create some other tag (e.g. TEXT_ONLY or HIDDEN or whatever) to distinguish those.

Then there's the case of 'PRIVATE' things that should not be used by users, but are used by external libraries - e.g. Internal directory in Standard.Database has a lot of PRIVATE types that must not be private because they are expected to be used by additional implementations of Database backends (e.g. Standard.AWS or Standard.Snowflake).

[GregoryTravis]

We need a way to mark certain pairs of libraries as "friends" to allow inter-library usage without possibly exposing internals to end users.