Ability to mark default constructor names for resolving return type

Hi!

A request to infer return value for default returns when calling a defined constructor function. EmmyLua supports this using a setting:

Here it can infer that calling e.g. :new() on items marked with the ---@class annotation will be returning an instance of that class.

This is especially useful when constructing classes using metatables in a generic class system, adding interfaces or inheritance functionality but still be able to denote the return type of calling the constructor method.

Example:

#class.lua

local definitions = {}

local Class = {}
function Class.class(name)
    local definitions = {}

    local def = definitions[name]
    if not def then
		def = {}
		def.__class_name = class_name

		def.new = function(self, ...)
	    	local instance = {}

	    	if instance.construct then
                instance:construct(...)
            end

            return instance
    	end

    	setmetatable(instance, def)

    	def[class_name] = def
	end

	return class_definition
end

Example of using the class creation method

#my_class.lua

local Class = require "path/class"

local MyClass = Class("MyClass")
function MyClass:construct()
	self._member = 0
end

Example of instantiating an instance of the class and showing the issue:

#example.lua

local MyClass = require "path/my_class"
local instance = MyClass:new() -- this line cannot find the function new() or deduce the return/type of "instance"

Here the instance of class return value from the new() function cannot be inferred and I haven't found a way to annotate this using luadocs with generics, alias, overload or other methods. This issue is somewhat related to #449 but I feel this warrants a retake on the proposed solution unless I am missing something?

A different way could be to allow explicit descriptors of the @field annotation to specify return value types in class definitions e.g.

The return values of functions defined in fields from a set metatable cannot have it's return type defined however it seems.

Start with the class.lua and example.lua scenarios in the issue, focusing on how the ---@class annotation and new() call are resolved. Review the related discussion in issue #449 and the described @field alternative before choosing an approach. Done should include inferred constructor availability and the correct instance return type for the example.