[FEAT] Resource Types

We propose a new feature called **Resource Types**, which introduces a composable entity framework for defining and managing custom resource types dynamically. This feature is inspired by Orchard Core's Content Types but adapted for Elsa Workflows to allow developers and users to build modular and extensible entities.

### What are Resource Types?

A **Resource Type** is essentially a document composed of **Resource Parts**, with each **Resource Part** containing 0 or more **Resource Fields**. This structure is entirely composable at runtime by the user:

- **Resource Type**: A named entity that can hold multiple parts and fields.
- **Resource Part**: A component of the resource, represented by a .NET type that provides specific properties and behaviors.
- **Resource Field**: Fields attached to a part, also represented by .NET types that define different field types.

**Example**:
Consider a `Workflow` resource type composed of several parts: `WorkflowDefinitionPart`, `TitlePart`, `DescriptionPart`, and `OwnerPart`. Users can dynamically create resource types and attach relevant parts and fields, allowing for full flexibility and extensibility.

```json
{
"Name": "Workflow",
"Versioned": true,
"WorkflowPart":
{
"Enabled": "BooleanField"
},
"WorkflowDefinitionPart": {},
"TitlePart": {},
"DescriptionPart": {}
"OwnerPart": {}
}
```

The above is an example of a Resource Type Definition.
With that in place, the user can now create Resources instances of the Workflow resource type that might looks like this:

json
{
"Id": "some-guid-specific-for-this-version",
"ResourceId": "some-logical-guid-for-this-resource-that-is-the-same-across-its-versions",
"Version": 1,
"ResourceType": "Workflow",
"WorkflowPart": { "Enabled": { "Value": true } }
"WorkflowDefinitionPart": { "workflow data created by the designer goes here" },
"TitlePart": { "Title": "Hello World Workflow" },
"DescriptionPart": { "Description": "My very first workflow" }
"OwnerPart": { "UserName": "Alice" }
}

### Why do we need Resource Types?

1. **Modular & Extensible Architecture**: By using composable **Resource Parts**, the system can flexibly support new entities (e.g., Workflow, Secrets, Agents, Webhooks) without hard-coding them. Developers can extend the system by adding custom parts to existing resource types without inverse dependencies on the core framework.

2. **Reusability**: Common behaviors can be encapsulated in reusable parts. For example, a "Tags" part can be applied to various entities (Workflows, Secrets) without duplicating code or creating dependencies between core and third-party modules.

3. **Automatic Versioning**: Each resource will inherently support versioning, eliminating the need to manually copy and paste version-related fields (e.g., `Version`, `IsPublished`, `IsLatest`) across different entity classes. This reduces redundancy and ensures consistency.

4. **Dynamic UI Generation**: Resource types and their parts can be managed through a UI where the editor dynamically composes itself based on available display drivers. This allows users to define and manage entities visually.

### Additional Benefits:
- **Extensible Resource Field Types**: Developers can create new field types, attach them to parts, and reuse them across multiple entities, fostering modular design patterns.
- **Pluggable Architecture**: Third-party modules can inject new resource parts into existing types, making the system more flexible and accommodating for different use cases without core modifications.

### YesSQL

The Resources framework is extensible and allows other modules to introduce custom aspect and facet types.

At the same time, we should be able to query resources matching properties on these aspects, exactly like we can do with YesSql when querying documents. And exactly like what we can do with Orchard Core Content Items and Parts.

For this reason, we must use a single ORM that supports this feature, which is YesSql.

We propose therefore that this feature will introduce a separate tier on top of which we can build applications, including workflow applications leveraging Elsa.