### Godot version

v4.0.beta10.official [d0398f62f]

### System information

Ubuntu 20.04, Ryzen 2700X, GTX 1070

### Issue description

Basic example code:
```gdscript
# Food is only there to demonstrate that it isn't a base class issue,
# but that the buck indeed stops with Fruit due to its defined _init.
class Food:
	var loadable := false

class Fruit extends Food:
	var flying := false

	func _init():
		pass

# Berry is only there to demonstrate that the buck doesn't stop with
# the parent class, but indeed is passed on to Fruit, since we don't
# have an _init defined here.
class Berry extends Fruit:
	var explody := false

# Since neither this class nor Berry have an _init defined, this will
# be inferred as Fruit, not Melon.
class Melon extends Berry:
	var extra_splashy := false
	
# Problem:
# There is an _init defined in Fruit, but not in Melon or Berry, so this
# is inferred by the editor as Fruit instead of Melon.
var melon := Melon.new()

# This works, demonstrating that godot indeed understands this as `Melon`.
print(melon.extra_splashy)
```

At runtime, `melon` behaves as expected, but in terms of properties the editor's code completion only offers `loadable` (from grand grand parent `Food`) and `flying` (from grand parent `Fruit`, which has `_init`) from the class hierarchy, but not `explody` (from parent `Berry`) or `extra_splashy` (`Melon` - itself). Every subclass in the hierarchy past `Fruit`, which is the one with `_init`, is ignored.

Also, when using VSCode the hover-tooltip shows `Fruit` as the type of `melon`, with the same above-described completion behaviour as in Godot's builtin editor.

What I'd expect: That `melon` is type-inferred as `Melon`, not `Fruit`.

### Steps to reproduce

The minimal reproduction project contains `bug.gd`, which has three sets of classes and corresponding examples in `_ready`. The first set demonstrates how no `_init` in the parent leads to correct type inference, the second demonstrates the problem using the Fruit example, and the third is a bit superfluous, but shows a parent and subclass who both have `_init` defined, which works as expected.

A few lines are dedicated for uncommenting for easy experimenting, with comments explaining what to do.

The project can be run in order to observe the runtime behaviour of the Fruit example. It should print: `This melon is extra splashy: false`, demonstrating how a `Melon` object which is inferred as `Fruit` indeed has the `extra_splashy` property of `Melon`, despite not showing up in the code completion drop-down.

### Minimal reproduction project

[subclass_init_infer_bug.zip](https://github.com/godotengine/godot/files/10304903/subclass_init_infer_bug.zip)

MethodInfo method_info;
		if (ClassDB::has_property(native, name)) {
			StringName getter_name = ClassDB::get_property_getter(native, name);
			MethodBind *getter = ClassDB::get_method(native, getter_name);
			if (getter != nullptr) {
				p_identifier->set_datatype(type_from_property(getter->get_return_info()));
				p_identifier->source = GDScriptParser::IdentifierNode::INHERITED_VARIABLE;
			}
			return;
		}
		if (ClassDB::get_method_info(native, name, &method_info)) {
			
			p_identifier->set_datatype(make_callable_type(method_info));
			p_identifier->source = GDScriptParser::IdentifierNode::INHERITED_VARIABLE;
			return;
		}
		if (ClassDB::get_signal(native, name, &method_info)) {
			
			p_identifier->set_datatype(make_signal_type(method_info));
			p_identifier->source = GDScriptParser::IdentifierNode::INHERITED_VARIABLE;
			return;
		}
		if (ClassDB::has_enum(native, name)) {
			p_identifier->set_datatype(make_native_enum_type(native, name));
			p_identifier->source = GDScriptParser::IdentifierNode::MEMBER_CONSTANT;
			return;
		}
		bool valid = false;
		int64_t int_constant = ClassDB::get_integer_constant(native, name, &valid);
		if (valid) {