Request: Support `@field` in both enum and table definitions.

Nobody has claimed this yet.

Request: Allow adding a field type to tables and enum definitions using the `@field` annotation.

This is useful for generating meta files from C code where there is no Lua table literal to copy.

See current behaviour below:

## `@class`
### ✅ Using `@field`
```lua
---@class Foo
---@field myField 5
Foo = {}
```
### ✅ Using literal code
```lua
---@class Foo
Foo = {
myField = 5,
}
```
### ✅ Using type annotation
```lua
---@class Foo
Foo = {
---@type 5
myField = nil,
}
```
## `@enum`
### ❌ Using field
```lua
---@enum Foo
---@field myField 5
Foo = {}
```
`Error: The field must be defined after the class.Lua Diagnostics.(doc-field-no-class)`
### ✅ Using literal code
```lua
---@enum Foo
Foo = {
myField = 5,
}
```
### ✅ Using type annotation
```lua
---@enum Foo
Foo = {
---@type 5
myField = nil,
}
```
## Untyped table
### ❌ Using field
```lua
---@field myField 5
Foo = {}
```
`Error: The field must be defined after the class.Lua Diagnostics.(doc-field-no-class)`
### ✅ Using literal code
```lua
Foo = {
myField = 5,
}
```
### ✅ Using type annotation
```lua
Foo = {
---@type 5
myField = nil,
}
```

Start by tracing the @field handling associated with the doc-field-no-class diagnostic; the issue provides Lua examples for @class, @enum, and untyped tables. Done means @field definitions work for enum and table definitions like the examples without that diagnostic, while the existing class behavior remains supported.

Written by the indexing model from the issue text.