Introduce Values to support expressions

[flyingsilverfin]

What is the goal of this PR?

Introduce the 'Value' type, which is returned as the result of an expression's computation. This change follows from typedb/typeql#260, which outlines the capabilities of the new expression syntax.

Values (representing any of Long, Double, Boolean, String, or DateTime) are returned as part of ConceptMap answers and are subtypes of Concept for the time being. Their main API is made of the .getValue() method and .getValueType() method, along with all the standard safe downcasting methods to convert a Concept into a Value, using Concept.isValue() and Concept.asValue().

We also move the import location of ValueType from being nested in AttributeType to Concept.

What are the changes implemented in this PR?

• Introduces the Value concept and the required ValueImpl that implements it
• Refactor ValueType to no longer live within AttributeType - now it exists in Concept.ValueType
• Updates the test framework for tests involving values, including the new ExpressionTest behaviour scenarios, which we also add to CI

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