fix argument ref in (dap--create-session)

[parsoj]

I'm seeing an issue while trying to set up a new/custom dap provider.

The debugPort argument referenced in the docs:

dap-mode/docs/page/adding-debug-server.md

Line 23 in 76cad34

(plist-put conf :debugPort 1234)

Suggests the following:

  (dap-register-debug-provider
  "dlv"
  (lambda (conf)
    (plist-put conf :debugPort 40001)
    (plist-put conf :host "127.0.0.1")
    conf))

however debugPort isn't being read in on the call to (dap--open-network-stream)

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 make-network-process(:name "go delve<1>" :buffer nil :host "127.0.0.1" :service nil :nowait nil :tls-parameters nil)
 open-network-stream("go delve<1>" nil "127.0.0.1" nil :type plain :coding no-conversion)
 dap--open-network-stream("go delve<1>" "127.0.0.1" nil)
 dap--create-session((:type "dlv" :request "attach" :mode "remote" :args "" :name "go delve<1>" :program nil :envFile nil :port 40001 :env nil :debugPort 40001 :host "127.0.0.1"))
 dap-start-debugging-noexpand((:type "dlv" :request "attach" :mode "remote" :args "" :name "go delve<1>" :program nil :envFile nil :port 40001 :env nil :debugPort 40001 :host "127.0.0.1"))

It appears that the argument that sets the port is actually called debugServer.
when i register a dap provider this way, it works for me and I connect to the debug server just fine:

  (dap-register-debug-provider
  "dlv"
  (lambda (conf)
    (plist-put conf :host "127.0.0.1")
    (plist-put conf :debugServer 40001)
    conf))

However, I think that this debugServer argument might conflict with the docs, and is maybe a bit of a confusing naming.

Digging through the issue history it looks like some others have run into the same thing and a similar fix worked for several of them:
#543
#7
#31
#479

But I haven't seen a PR up for this, yet - so I figured I'd get the ball rolling!

[eshelyaron]

I've just hit this issue as well, I thought of putting together a PR as this is quite a "gotcha", and was glad to see someone already did :)

One thing to note though is that a backward-compatible solution may be preferable. A quick GitHub search shows at least one more project that is already using debugServer.
Maybe accept both options and prefer debugPort?