feat: add hostname option to set the interface to bind to (xdebug#330)

fix: do not send continue events (xdebug#307)

A debug adapter is not expected to send this event in response to a request that implies that execution continues, e.g. 'launch' or 'continue'.
It is only necessary to send a 'continued' event if there was no previous request that implied this.

Note: there is still the problem that it will seem to "hang" when you continue and the PHP code takes a while to run, xdebug#308 will fix that.

Fixes xdebug#301

fix: avoid deadlock with multiple connections when executing code (xd…

…ebug#294)

This introduces a new concept in the xDebug connection:  "execution commands": these are commands that result in PHP being executed.  The way xDebug works, if one of these commands is run, that connection is hung until the PHP code is done executing (until it gets to the next stopping point).  By keeping track of when such commands are still in progress, and making it something that the adapter can check, it allows the adapter to specifically code for when the connection is currently hung.  Which allows preventing the deadlock situation described in xdebug#164 

The adapter also now emits `before-execution-command` since it results in possibly going into a hung state for a while.  The adapter uses that event to send a `ContinueEvent`, this is just a side advantage that makes the interface more responsive.  Before when you click continue, if the PHP code is hung for whatever reason (it is slow, it has a lot to do, etc), it appears that it did not work as it appears to still be stopped on a breakpoint (but it is not, which you can tell by trying to view any of the details in the debug pane).  With the change, now when you click continue it immediately changes the process back to "running" state which is more truthful.

Since xdebug#164 has a lot of comments, here is the **tl;dr:** deadlock explanation: 
1. Connection 1 makes a second connection with curl.
2. It sends command to all connections to set breakpoints, and waits for response.
3. The second connection hangs as it is waiting for connection 1 to set breakpoints, connection 1 hangs without setting those breakpoints because it is waiting for connection 2 to respond and can't do anything until that completes.

This PR makes it not wait for the breakpoints to be set on a connection if the connection is waiting for code to execute.  So now connection 2 can finish initializing and run, no more deadlock.

Fixes xdebug#164

ci(release): set prepare for semantic-release-vsce

fix(phpDebug): make connection init more robust (xdebug#243)

Move 'started' event after Xdebug settings have been set to make sure that 'run' is not executed before settings are processed and make sure that invalid settings don't prevent init from completing. Add some line feeds to output messages.

Send error responses instead of just shutting down so that e.g. EADDRINUSE caused by debugger being already active in another window doesn't result in an invalid state.

ci(travis): use npm 5 in release stage

fix: properly build before releasing

feat: path mappings (xdebug#175)

Adds support for mapping multiple server source roots to local roots.

Closes xdebug#54

1.11.1

1.11.0