debug: forward initializeRequest to delve dap to verify capabilities

[hyangah]

The thin dlvDapAdapter2 currently handles initializeRequest because delve hasn't been
launched yet. Delve will start responding to DAP requests after launchRequest is received.
This is not ideal - delve should be the one that tells us about its capabilities.

From the current comment:

		// We respond to InitializeRequest here, because Delve hasn't been
		// launched yet. Delve will start responding to DAP requests after
		// LaunchRequest is received, which tell us how to start it.

		// TODO: we could send an InitializeRequest to Delve when
		// it launches, wait for its response and sanity check the capabilities
		// it reports. Once DAP support in Delve is complete, this can be part
		// of making sure that the "dlv" binary we find is sufficiently
		// up-to-date to talk DAP with us.

[polinasok]

If you launch or attach to delve in or before the initialize request (before the decision to add a thin adapter we considered launching delve in goDebugConfiguration where we have access to the launch attributes), then you can get capabilities in real time. Another option is to leave everything as is, only sending back the most minimal set of capabilities from the thin adapter (e.g. configuration done only), then do the forwarding that the comment talks about and communicate back to the editor what the reality is with Capabilities event.

[gopherbot]

Change https://golang.org/cl/268460 mentions this issue: src/debugAdapter2: supply launch in the debug session creation time

[gopherbot]

Change https://golang.org/cl/290449 mentions this issue: src/debugAdapter2: remove thin adapter for dlv-dap