Support generalised annotations and uniqueness

[flyingsilverfin]

What is the goal of this PR?

We update the Typedb Protocol and TypeQL to the latest versions, which support the uniqueness annotation and generalised Type APIs. These generalised APIs allow querying by a set of annotations, rather than just boolean = true|false.

For example, the API: AttributeType.get_owners(onlyKey: boolean), has become: AttributeType.get_owners(annotations: Set["Annotation"])

All usages of boolean flags to indicate key-ness should be replaced by a set of ThingType.AnnotationEnum.KEY. The new @unique annotation is available as ThingType.AnnotationEnum.KEY, and also usable within the APIs that accept annotations.

What are the changes implemented in this PR?

• Update dependencies to include generalised annotations in the language and protocol. We also pull the behaviour repository to include tests for generalised annotations
• We reflect the changes to the behaviour test steps in the implementation of BDD steps, in particular with extensions for generalised annotations
• Update Concept API methods to remove the *_key boolean and replace it with a set of flags from ThingType.Annotation

Related protocol changes: typedb/typedb-protocol#182 and typedb/typedb-protocol@de4f5b4

Related core changes: typedb/typedb#6775 , typedb/typedb@e24cfa9 , and typedb/typedb@b16cdb0

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

[flyingsilverfin]

Python's new conventions means we have to use properly named pre-releases. Until python can be a rust-wrapped client, we will use this convention and release snapshots for Python manually.