[Request] Improve support for custom number types

Personne n'a encore pris cette issue.

In the builtin definitions, the `integer` type is defined as a child class of the `number` type:
```Lua
---@class integer : number
```
Despite that, it is still possible to write such code without any type-checking errors:
```Lua
---@param lives integer
local function printLives(lives)
print(lives)
end

---@type number
local lives = 9.0
printLives(lives)
```
I think this is fine, it makes sense.

However, this behaviour seems to be hardcoded in the extension.
Many of the functions from the API I use expect fixed-point values as parameters; such arguments are indicated by the `fixed` type, which is an alternate number type defined in much the same way as `integer`:
```Lua
---@class fixed : number
```
To represent literal fixed-point values, the API provides a unit contant which is used something like this:
```Lua
move(4*UNIT, 10*UNIT, UNIT*3/2) -- 40.0, 100.0, 1.5
```

Technically, `fixed` is just a regular number, however it is extremely helpful to the user to see this:
rather than this:

In older versions of the extension, this works perfectly fine; however, recent versions perform type-checking, which is a very useful feature but does not work nicely with the `fixed` type:
It looks like the extension considers `number * fixed` to be a `number`, which is a reasonable guess, but causes the error shown in the image above.

To solve this, I have thought of the following solutions:
1. Completely disabling type-checking. It works, obviously, but it would be preferable to not have to give up on such a useful feature.
2. Manually casting every literal value. This works too, but is extremely unpractical and results in bloating code.
3. Somehow make it so that `number * fixed` resolves to `fixed` instead of `number`. But that sounds like a very arbitrary solution to me.
4. Defining `fixed` as an alias: `---@alias fixed number`. It prevents the error from occuring, and the code is readable, but the completion/hover hints show "number" instead of "fixed", like in the second image.
5. Forking the extension to add a special case in the type checker.

There may also be other solutions I am not aware of, but my first impression is that solution 4 suits my usecase best, and would probably be perfect if there was some way to make an alias that behaves like in the first image (much like `typedef` in C, for instance).

Commencez par les définitions intégrées de `integer` et `number`, puis suivez le comportement du vérificateur de types pour les opérations arithmétiques impliquant des types numériques personnalisés tels que `fixed`. C’est terminé lorsque les types numériques personnalisés conservent des informations utiles de vérification de types et de complétion ou de survol sans nécessiter de casts, tout en préservant le comportement existant de `integer`.

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