feat(api): Add additional fields to `EntityVersion` GraphQL object

#### Motivation
Add more contextual information to entity version objects to navigate historical data more effectively.

#### Implementation
Add the following fields to the `EntityVersion` GraphQL object:
```graphql
type EntityVersion {
# Version id
id: String!

# (NEW) Timestamp of when the edit was proposed (optional since doesn't apply to personal spaces and space imports)
proposedAt: String,
# (NEW) Block number of when the edit was proposed
proposedAtBlock: String,
# (NEW) Timestamp of when the edit was published/executed (null if still a proposal)
publishedAt: String
# (NEW) Block number of when the edit was proposed
publishedAtBlock: String

# (NEW) Author of the proposal for the edit
author: String!

# (NEW) List of attributes changed as part of the edit
updatedAttributes: [Triple!]!

# (NEW) Name of the entity at the time of the edit
name: String
# (NEW) Description of the entity at the time of the edit
description: String
# (NEW) Cover of the entity at the time of the edit
cover: String
# (NEW) Types of the entity at the time of the edit
types: [Entity!]!
# (NEW) Blocks of the entity at the time of the edit
blocks: [Entity!]!

# Entity attributes as of this version
attributes(filter: AttributeFilter): [Triple!]!
}
```
#### Alternatives
Since the `EntityVersion` object is getting quite complex (having both fields related to the version as well as all other entity fields), it might be worth refactoring the API and separating those.

Here would be an alternative design
```graphql
type Query {
# (NEW) Fetch all versions for an entity
entityVersions(entityId: String): [EntityVersion!]!
}

type EntityVersion {
# Version id
id: String!

# (NEW) Timestamp of when the edit was proposed (optional since doesn't apply to personal spaces and space imports)
proposedAt: String,
# (NEW) Block number of when the edit was proposed
proposedAtBlock: String,
# (NEW) Timestamp of when the edit was published/executed (null if still a proposal)
publishedAt: String
# (NEW) Block number of when the edit was proposed
publishedAtBlock: String

# (NEW) Author of the proposal for the edit
author: String!

# (NEW) List of attributes changed as part of the edit
updatedAttributes: [Triple!]!

# (NEW) Relation to the entity at the time of the edit
entity: Entity!
}

type Entity {
# (REMOVE)
# versions: [EntityVersion!]!

# (NEW) Version of the selected entity
version: EntityVersion!
...
}
```

With this design, the query to get multiple versions of an entity would look like this:
```graphql
query {
entityVersions(entityId: "Foo", spaceId: "MySpace") {
entity {
name
}
}
}
```

Instead of
```graphql
query {
entity(entityId: "Foo", spaceId: "MySpace") {
versions {
name
}
}
}
```

Moreover, since versions are not really bound to entities, but rather to edits, it might make sense to change the naming of `EntityVersion` to `EntityEdit`, `Edit` or something along those lines.

The issue is about extending the GraphQL schema for EntityVersion in a Rust project. Look for the GraphQL type definitions, likely in a schema file, and the corresponding Rust structs that implement these types. The work involves adding new fields and potentially refactoring the API structure. Check existing queries and mutations to understand how versions are currently fetched and used. A newcomer would need to understand the project's GraphQL setup and data flow.

索引モデルが issue の本文から書いたものです。