The word "debug" no longer bears any meaning for me.

This is extremely POC and not ready for any serious review as of yet, but I'm making this pr to get some feedback on what I have so far.

This adds the capability to interactively debug SWFs running under Ruffle, the current protocol is not compatible with FDB or JPEXS as of yet (see below) however does have a couple of advantages:

• Due to it being based on WebSockets, it should be possible to use this to debug SWFs running on web and extension platforms, (FDB uses raw TCP so this won't be possible)
• Ability to add Ruffle-specific functionality, such as commands that interact with our various backends (I see this being useful for debugging rending issues specifically)
  Additionally, while JPEXS devs have done some reverse-engineering of the FDB protocol, this is mainly from the debugger side, so figuring out the debugee side will require some additional work.

Currently this implementation provides:

• A implementation of a debugging backend for desktop only, using tungstenite for websockets, as web will require the use of a different library
• A basic, tui debugger, for details of available commands, see debugger/src/command_parser.rs
• Debugging functionality for AVM1 only

Currently all changes to both desktop and core are blocked behind the debugger feature, it's intended that these changes should have no effect when that feature is not enabled.

Note that versions of Flash Player intended for debugging restrict the ability to debug "production" SWF files that do not contain EnableDebugger2 tags and the like, it is intentional that this debugging feature does not enforce this, nor should it depend on any of the debugging specific information that can be embedded in SWFs using AVM2 where feasible. Any site that would like to prevent debugging should simply not enable the debugging feature (which will be disabled by default). This tooling is intended for use by Ruffle contributors for understanding and resolving issues first and foremost, and hence needs to be "useful" in as many scenarios as possible.

Things to be figured out:

• Are there any other features we want
• Do we want to handle FDB via a separate backend or by using some kind of proxy, the later would allow us to use JPEXS debugger on web at the cost of needing to run some kind of bridge
• Do we want any other debugging features?
• Should the debugger be in-tree or a separate repo?