Improve function and signal parameter highlighting, add shadowing warning

[ckaiser]

I noticed that signal parameters got highlighted as class names if they matched, so it could potentially be confusing to see a signal declared as signal name(bool), since at first glance it might seem like it accepts only booleans, when in fact that's just the parameter name. I also added a warning when any signal parameters shadow global class names, to discourage it.

This led me down a bit of a rabbit hole with regards to syntax highlighting for function parameters in general, which suffered from the same problem, but the fix was similar to the one for signals except lambdas which was a bit more complicated since those were not being flagged properly when there was a space after the func token.

I attempted a fix for that as well, although I'm not super familiar with this kind of code so there may be a cleaner fix.

Before:

After:

[Calinou]

Tested locally (rebased on top of master 39fc116), it works as expected.

Before	After

Code used in the screenshots

extends Node2D

signal _int(int)
signal _int2(int: int)

var _bool: bool = false


func bool(_bool: bool) -> bool:
	_int.emit(1)
	_int2.emit(2)
	return _bool


func _ready() -> void:
	var _float = func float(_float: float) -> float: return _float
	bool(_bool)

[leandro-benedet-garcia]

I would think it's better to get an exception for trying to override a built in type, tho?

[Mickeon]

I would think it's better to get an exception for trying to override a built in type, tho?

The PR showcases and addresses an edge-case in the highlighter's logic which is potentially confusing, especially for beginners. Whether an error should be printed is not relevant (_{Although at most it should be a warning})