chore: introduce the Visitor pattern

[asterite]

Description

Problem

I wanted to try to implement LSP code actions, or show hover information when hovering over types like i32, Field, etc., but for all of that I'd need to "visit" the AST again. I've been thinking how to do it with a visitor and I think I got to something that looks good, is convenient and reduces the amount of code and the boilerplate logic a lot... so implementing more LSP features should be easier (or less tedious) from now on.

Summary

Implements the Visitor pattern and uses it in LSP completion, signature help, document symbol and inlay hints. Expression, UnresolvedType and LValue are visited, but not UnresolvedTypeExpression but only because that isn't currently of interest... but it can be recursively visited later on if we need that.

Even though the diff shows that there is more code now, it's because the AST is thoroughly visited and exposed, and I also found a couple of cases where we weren't visiting all nodes... so this PR should also improve existing LSP functionality a bit.

Additional Context

None.

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 8b0c47a0715b82c4ae2555168d100a53a44f8a69, compared to commit: 31e9be6b83b448eb6834645dc124589dc724a7b2

There are no changes in circuit sizes

[jfecher]

I didn't look into this too closely but if you think it's an improvement we can merge it

[asterite]

I didn't look into this too closely but if you think it's an improvement we can merge it

Thank you! Yes, it'll make it much easier (or less boilerplate-y) to implement a few remaining LSP things.