feat - improve support for monorepos and fvm in monorepos

[kaerumm]

flutter-tools uses the active buffer's LSP client's root_dir as the cwd for executing commands. This is fine for a single project repository as the root_dir is set to be that project's root directory. But when working with monorepos this approach does not work, as the LSP's root_dir is whatever project was first opened when attaching the LSP.

Also when using FVM, flutter-tools does not consider the possibility of having multiple flutter versions, and instead keeps attached
the first LSP that it found.

To properly support monorepos we then have to do two things:

1. For executing commands on the correct project we have to correctly find the current buffer's opened file's project root, this can be done by traversing upwards from the current file until we find the root indicators
2. Attach the proper LSP version to the current buffer, this can be done by also traversing upwards but this time looking
   for a .fvm folder, and then using that folder's flutter sdk.

This PR does precisely that, while also moving things around to keep code clean, here is a list of the changes done by scrolling-down-to-the-end-of-the-pr order:

1. Moved the attach call to an autocmd on buffer/file pair open.
2. Moved get_absolute_path to path utils so it can also be used by get_cwd that is now moved to config_utils
3. Moved get_cwd to config_utils so it can be used in fvm_utils
4. Changed get_cwd to use it from its new location
5. Renamed get_lsp_root_dir to get_project_root_dir to reflect its new behaviour
6. Fixed the call to _flutter_sdk_root erroring when the flutter executable could not be found
7. Moved fvm-related functions to its own file fvm_utils and added fvm_dir to the paths so that it can be used as the
   root directory for the LSP
8. Adapted the call to get_default_binaries to account for the fact it can return null
9. Changed get_lsp_root_dir into get_project_root_dir which traverses upwards trying to find the configured
   project root patterns until it finds the first one, which will then be used as the root directory for commands.
   If it is unable to find a root directory by that method, we fallback to the old behaviour of returning the active lsp's root_dir
10. When using fvm, we no longer cache the paths as the executable paths can change on a file-by-file basis, and caching would require a more complex caching mechanism that is faster than just traversing and looking for a .fvm. I judged the effort to think up a caching strategy not needed at the moment because traversing upwards is not that expensive and we don't do it that frequently, but left a TODO in case my judgment was incorrect.
11. Fixed a tried to access on null when paths is null

When using FVM this PR changes flutter-tools so that it might run multiple Dart LSP servers, I thought about giving an option of keeping only the most recently launched LSP and closing the rest since the Dart LSP can be quite resource intensive, but didn't go through implementing that since I don't really have the time right now.

[sidlatau]

I tried to test but I get an error on opening:

Error in .nvim.lua:
Lua: ...lazy/flutter-tools.nvim/lua/flutter-tools/utils/path.lua:57: invalid value (boolean) at index 1 in table for 'concat'
stack traceback:
	[C]: in function 'concat'
	...lazy/flutter-tools.nvim/lua/flutter-tools/utils/path.lua:57: in function 'join'
	...y/flutter-tools.nvim/lua/flutter-tools/lsp/fvm_utils.lua:26: in function 'flutter_bin_from_fvm'
	...lazy/flutter-tools.nvim/lua/flutter-tools/executable.lua:106: in function 'get'
	...e/nvim/lazy/flutter-tools.nvim/lua/flutter-tools/dap.lua:7: in function 'setup'
	...share/nvim/lazy/flutter-tools.nvim/lua/flutter-tools.lua:65: in function 'start'
	...share/nvim/lazy/flutter-tools.nvim/lua/flutter-tools.lua:129: in function 'setup_project'
	[string "<nvim>"]:1: in main chunk