Schema editor loop fix

[jamesreprise]

What is the goal of this PR?

We've fixed a bug in the schema editor where it would enter a loop through a few layers of indirection. The core loop of this was:

1. We load the constraints for a type B as a consequence of the user double clicking on it in the type browser.
2. We load B's supertypes.
3. B has a supertype A.
4. We load the inheritables for A.
5. As a part of loading the inheritables for A, we load its owned attribute types.
6. A has an owned attribute, we'll call it name. B is a subtype of A, so it inherits name as well, becoming an owner type of name.
7. We load the owner types for name, of which B is one.
8. GOTO 2.

What are the changes implemented in this PR?

We've introduced the use of some AtomicBooleans, keeping track of what states are and aren't loaded. This also prevents us unnecessarily reloading data.

Before deciding to load a state, we check whether we've already loaded it. If we haven't, we add the fact that we have by flipping the relevant boolean. When any transaction is opened or a write transaction is performed, we flip all the booleans back to false to reflect the fact that our data is out of date.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.