Registering cons the normal way provides proper defaulted arguments support

[JaroslavTulach]

Pull Request Description

• Fixes Default arguments are not being applied in constructors of builtin types #13664 by removing many @Builtin_Type annotations
• There no point to treat regular types with Atom instances as builtin types
  • only special types like Vector or Date are really builtin types
• encapsulation of private constructors is now enforced as demonstrated by a8f956d
• side effect: expression messages are now human readable even without import Standard.Base

Important Notes

• I was oscillating among various options
  • this quote questions why Fix problems when entering a partially applied function with typed arguments #13646 makes the Missing_Argument a @Builtin_Type at all?
  • very likely _the only benefit is ability to instantiate it from Java!
  • In such case we should look at removing cases where @Builtin_Type is used just for this purpose
• this line of thought is subject of this PR

Rejected

• The other rejected option is to fix the registration of constructors
  • 09de69e does that for Missing_Argument only
  • because doing the same registration for all tp.builtinType() makes the runtime "fubar"
  • along this direction I try to investigate what builtins can be registered and what cannot before "fubar" happens

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• Unit tests have been adjusted
• Benchmarks aren't affected
  • engine run
  • stdlib run

[JaroslavTulach]

• This is the deadlock.txt I have seen.
• Happens when guest-code wants to initialize Java while some other thread is calling Context.close()
• I guess we don't need 100% correctness here
  • after 10s lets give up
  • close the context while a thread is still running

[JaroslavTulach]

• Some failing tests to fix:
• hopefully addressed by 3627ceb

/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.BuiltinTypesTest.xml 5✅ 11❌ 661s
org.enso.interpreter.test.instrument.RuntimeAsyncCommandsTest.xml](https://github.com/enso-org/enso/runs/60350917388#r62) 2✅ 5❌ 96s
/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeExecutionEnvironmentTest.xml 2✅ 638ms
/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeInstrumentTest.xml 6✅ 6❌ 4⚪ 361s
[/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeProjectContextTest.xml]/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeRefactoringTest.xml 15❌ 241s
/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeServerTest.xml 77✅ 6❌ 2⚪ 86s
/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeSuggestionUpdatesTest.xml 4✅ 5❌ 301s
/runner/_work/enso/enso/target/test-results/TEST-org.enso.interpreter.test.instrument.RuntimeTextEditsTest.xml 1❌

[Akirathan]

Decreasing the number of builtins seems like a good path.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2026-01-16):

Progress: .

• merged @Builtin_Type Registering cons the normal way provides proper defaulted arguments support #14611
• merged Time_Of_Day Arrow storage: Arrow storage for Time_Of_Day #14646
• libs standup
• sped up VSCode debugging 4x times: Speeding up Truffle debugging apache/netbeans#9142 (comment) - still some improvements needed
• attempt to rewrite DateStorage to directly use ByteBuffer It should be finished by 2026-01-17.