The architecture refactor of 2023

[Groctel]

Hello everyone!

As you may have noticed, #723 has been stalled for six months. The idea of that PR was to refactor Neorg's core in a single, giant merge. Of course, it failed! Instead of submitting a single changeset, I'm creating this issue to track many, smaller PRs whose objective is to refactor Neorg and make it more robust and maintainable.

In order to do this, I'm first going to close #723. Then, I'm going to pull some changes from there and start opening many PRs to improve the code little by little. This issue should serve as a way to track all those changes and discuss about them.

If you'd like to discuss this project, please do so in this thread. I'm not on Discord most of the time and I will most probably never get your message. For whatever reason, I've never got mobile notifications working, so I won't be notified of any discussions outside of this.

What's this architecture refactor about?

The main idea of this project was to move the neorg global object into its own module so that it would be defined and imported as a local object. This would make the program's architecture more solid (pun intended) and make Neorg perform at better speed since many global table lookups would be avoided. In order to do so, many objects must be moved, redefined, split and refactored, so this is not a short endeavour at all.

When I started working on this, I began to find many places of improvement in the code's architecture, so I started tracking them and writing improvements. This is not a bug-fixing project. I may coincidentally fix some, but the main goal is to make Neorg easier to maintain so that it can evolve much more easily.

List of goals of this project:

Move neorg to its own core module

#1001. #1003

This is the main goal of the project. All modules should require the neorg.core module in order to use the neorg object. When this is done, I will check every single import list so that the correct symbols are always imported. Sequencing should not matter anymore.

Make the events API much lighter

Creating an event and broadcasting it to the different modules should be as fast as possible and should also be a very simple task from the broadcasters' side. If possible, sending an event should be handled in a declarative way so that it can be done in a single statement.

Making private parts of modules actually private

We should conceal the parts of the modules that we don't want the public to see and expose the modules with an actual API so that other modules can easily interact with them.

Documentation

Every function docstring has to be checked to confirm that symbols are referenced correctly.

Closing note

If there's anything that you'd like to add to the list just ask! Also, I understand that some of the changes may be opinionated and opinions may differ. Please do bring up your concerns in the discussion.

[Groctel]

@vhyrro: @max397574 reported that #1001 broke lazy loading. Should I re-force lazy loading or should I update the installation instructions to reflect this change?