[Request] Improve support for custom number types

In the builtin definitions, the integer type is defined as a child class of the number type:

---@class integer : number

Despite that, it is still possible to write such code without any type-checking errors:

---@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:

---@class fixed : number

To represent literal fixed-point values, the API provides a unit contant which is used something like this:

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).

Start with the builtin definitions for integer and number, then trace the type checker behavior for arithmetic involving custom number types such as fixed. Done means custom numeric types retain useful type-checking and completion or hover information without requiring casts, while preserving the existing integer behavior.