Fix ClassDB API type mismatch bug between --editor and player

There are two ways a class can be added to ClassDB:

- `A`: When an instance of the class is created for the first time. When
  this happends the class is not registered/exposed to scripts.
- `B`: When calling `GDREGISTER_CLASS(ClassName)` or similar. When this
  happens the class is registered/exposed to scripts.

ClassDB has an API type property to differentiate between the core
and editor APIs. Up until now the API type was determined whenever
the class is added to ClassDB (either `A` or `B`).

The problem comes when a class is instantiated (`A`) before
being registered (`B`).
If at this point the current defined API is not the same as when the
class is later registered, this will result in a mismatch between
`--editor` and non-editor apps.
This is specially bad for C# as it makes the editor player abort.

This was happening with `EditorPaths` which, while being registered
during the editor API classes registrations, it was also being
instantiated earlier when running the editor or the project manager,
via a call to `EditorPaths::create()`. This regression was introduced
in 1074017f043ec9155b12ea97cd00cf11361ccdf0.

This commit fixes this simply by re-assigning the class API type when
the class is registered (`B`).
This is correct because API type describes registered/exposed classes.
It shouldn't cause any regressions as the API type should not be
accessed of classes that are not (or not yet) registered/exposed.

Code locations for reference:
- Method to add a class to ClassDB: `ClassDB::_add_class2`
- Code that adds classes to ClassDB post first initialization (`A`):
  `memnew` macros -> `Object::_postinitialize` ->
  `Object::initialize_class` -> `ClassDB::_add_class2`.
- Code adds class to ClassDB and registers/exposes it to scripts:
  `GDREGISTER_CLASS` macros -> `ClassDB::register_class<T>` ->
  `Object::initialize_class` -> `ClassDB::_add_class2`.

0 files changed, 0 insertions, 0 deletions