Feature: namespaced type definitions

Personne n'a encore pris cette issue.

This is yet another feature/enhancement idea to make annotations easier to read/write. Perhaps it's come up before, but I couldn't find any issues or discussions about it.

It's wise to namespace type definitions to avoid collisions with type definitions from other code. This can lead to painfully long type names (e.g. `my-project.db.entities.Foo`). This idea allows defining namespaces for utility and syntactic sugar.

Here is a semi-realistic example and application of this idea:

- file: `./my-library/db.lua`

```lua
--- Namespace declaration
---
--- All types declared in this file will be prefixed with the `my-library.db` namespace
--- identifier when used elsewhere.
---
---@namespace my-library.db

--- Database connection Handle
-- Locally, this can be referenced as `connection`. Files/modules with different namespaces can
-- reference it by it's fully-qualified name, `my-library.db.connection`
--
---@class connection

--- Database Connection Options
--
---@class opts
---@field host string
---@field port number
---@field user string
---@field pass string

--- Establish a new DB connection
---@param opts opts
---@return connection? conn
---@return string? error
return function(opts) end
```

- file: `./my-library/db/migration.lua`
```lua

--- namespaces can be re-used
---@namespace my-library.db

--- usable locally as `migration.status`, exports as `my-library.db.migration.status`
---
---@alias migration.status
---| 0 # pending
---| 1 # executing
---| 2 # complete
---| 3 # error

--- exported as `my-library.db.migration.opts`
---
---@class migration.opts
---@field name string
---@field run_in_transaction boolean

---
---@class migration
---@field status migration.status
---@field name string
local migration = {}

--- Execute the migration
---@param db connection
---@return boolean ok
---@return string? error
function migration:exec(db) end

--- Check migration status
---@param db connection
---@return migration.status
function migration:status(db) end

local _M = {}

--- Create a new DB migration
---@param opts migration.opts
function _M.new(opts) end

--- List all migrations
---@param db connection
---@return migration[]
function _M.list(db) end

return _M
```

- file: `./my-library/utils.lua`
```lua
---@namespace my-library

local db = require "my-library.db"
local migrations = require "my-library.db.migrations"

local _M = {}

--- Check to see if any migrations need to be executed
---@param opts db.opts # options for connecting to the database server
function _M.check_migrations(opts)
-- the displayed type for `conn` is `db.connection`, because the current namespace is `my-library`
local conn = db(opts)

for _, m in ipairs(migrations.list(conn)) do
-- displayed type for `m` is `db.migration`
-- displayed type for `status` is `db.migration.status`
local status = m:status(conn)
print("migration: ", m.name, ", status: ", status)
end
end

return _M
```

* namespaces are just labels/aliases, so they can be shared and re-used between files
* types are resolved by checking the local namespace before searching the global namespace

L'issue fournit des fichiers Lua d'exemple dans ./my-library/db.lua, ./my-library/db/migration.lua et ./my-library/utils.lua, mais ne nomme aucun fichier d'implémentation ni aucun test dans le dépôt. Commencez par retracer la manière dont le serveur de langage résout actuellement les définitions de types et les annotations, puis déterminez comment les déclarations de namespace et les noms locaux par rapport aux noms entièrement qualifiés doivent être représentés. Le travail est terminé lorsque les classes avec namespace, les alias, les champs et les références sont résolus de manière cohérente dans tous les exemples.

Rédigé par le modèle d'indexation à partir du texte de l'issue.