[3.0] Change plays override from label to named_type to allow both scoped and not scoped labels

[farost]

Usage and product changes

Previously, we could only use not scoped labels (names without scopes) in as of plays. However, it can cause troubles while reading the schema by a human eye:

define
relation family relates father;
relation fathership relates father;

entity person plays family:father, plays fathership:father;

# It is fine: we can't have another "relates father" in family or fathership
relation subfamily sub family, relates subfather as father;
relation subfathership sub fathership, relates subfather as father;

# It creates more questions as subperson can play multiple `father`s
entity subperson sub person, plays subfamily:subfather as father, plays subfathership:subfather as father;

This PR allows us to use both entity subperson sub person, plays subfamily:subfather as family:father, plays subfathership:subfather as fathership:father; and entity subperson sub person, plays subfamily:subfather as father, plays subfathership:subfather as father; based on users' preferences.

Implementation

We use named_type for simplicity. However, it includes not only scoped labels and labels, but also builtin types, so the grammar becomes less strict.

We decide to move forward with this solution as:

• it is simpler and faster while not totally wrong, and the additional filtering is done on the server side;
• we are probably going to remove plays as soon, and this PR is mostly needed for compatibility with the current state of the server. However, we can discuss if we are happy with named_type in case we'll have the same issue when implementing the new "hiding" syntax.

[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

• [ ] 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.