Debug improvements

[fnzr]

This PR implements the following features related to https://github.com/lawrence-laz/neotest-zig/issues/9:

• Adds a configuration to customize the debugger adapter in the setup function

• Running the DAP strategy asynchronously builds the project using nio.control.future and native lua api (based on rustacean implementation of the same feature)

~* Checks for the existence of neotest_builder.zig and neotest_runner.zig in the project directory and only copies the defaults if they don't exist (allows customization of the handlers and avoids deleting user files)~ discarded

• Displays an error message on build errors with the vim.notify api.

• Selection of one output if the project emits more than one binary should work on the lua side, but I haven't tested it. I don't quite understand how to get the neotest_builder.zig to generate multiple binaries

[fnzr]

My worry is. if the user does have the neotest_build file in his repo, we would be overwriting then deleting it. I'm ok with skipping the check if you think that's not a big deal.

[lawrence-laz]

My worry is. if the user does have the neotest_build file in his repo, we would be overwriting then deleting it. I'm ok with skipping the check if you think that's not a big deal.

It's probably unlikely, but just to be on the safe side we could rename the file to something like __neotest_build.zig?

[fnzr]

nah, I think we either make a "feature" that the user can provide his own builder and read his (at the risk of running an outdated builder), or overwrite if the file exists, guaranteeing the adapter works as intended.

[lawrence-laz]

nah, I think we either make a "feature" that the user can provide his own builder and read his (at the risk of running an outdated builder), or overwrite if the file exists, guaranteeing the adapter works as intended.

I meant to rename the file we have to __neotest_build.zig to reduce collision chances to minimum. Although it's probably unlikely someone will have a neotest_build.zig file in their source.

I'd go with overwriting at least for now, because there's definitely a need for being able to update those .zig files from our side.

The idea as it currently is, is that the user is still in control of their build.zig file and neotest_build.zig file only imports and "decorates" the original user file with what the neotest-zig plugin needs.

[fnzr]

should be good to go