Add light graph theme

[jamesreprise]

What is the goal of this PR?

We've added a preference to change the theme of the graph visualiser. This has been requested so that people can print their graphs. End users are able to choose between a dark theme (as it currently exists within Studio) and a new, light theme for the graph output within the preferences dialog.

Contributors and developers should experience little difference, but now have a working example of a dropdown within the preferences dialog as well as an example of multiple preferences within a single preference group.

What are the changes implemented in this PR?

We've added a preference to change the theme of the graph visualiser. This does not affect the theming of the rest of Studio. As per the printer-friendly nature of the request, the background colour has been set to pure white (an off-white colour would still require colouring the background, wasting ink in ink-based printers).

This looks like this:

Feedback is welcome on the theme. Though there may be some increase in visibility and clarity gained by changing smaller details such as the edge and inference colouring, I believe the existing theme is ready for production.

We've introduced:

• a CommonPalette into framework/common/theme/Color as many of the colours between the two graph themes are shared.
• a LIGHT_GRAPH GraphTheme into Theme in framework/common/theme/Color.
• a "Set Graph Theme" preference in the preference dialog, along with the requisite properties into DataManger and PreferenceManager

Additional information

Closes:

• https://github.com/vaticle/typedb-studio/issues/631

[grabl]

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.

---

Code

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

Architecture

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

[jamesreprise]

Closing this for now as it's become stale after having been abandoned for too long. We can use this branch as a blueprint for future plans, but we know the preferences architecture has to change to support this.