Decide if this project should be the one to help PT get off the island

[certaintls]

This project implements Pluggable Transport Specification - Dispatcher IPC Interface

However, the majority of users that use circumvention today do not run a few specific circumvention applications like Tor browser to access New York Times. Instead, they run general purpose proxies or tunnels that work with their existing applications to access the content. One can argue that the end users appreciate the experience and journey of staying in the original apps. Regardless, supporting a new segment of audience – the end user – may not sound as ambitious as it appears, as the Dispatcher (specified by PT3.0) is already an application that can run on both client and server sides. For example, an end user can set up dispatcher transparent TCP mode, and let another application like SSH to run through it. The user can even run sshuttle through dispatcher transparent TCP mode to establish a simple VPN in a few commands.

However, what's missing are:

1. Support general SOCKS5. The dispatch currently supports a specific use case of SOCKS5 for PT aware applications. Once we support SOCKS5 for general purpose, we can reach much larger audience (and getting much more open source community contribution). This feature can also improve developer onboarding experience, as it can offer a faster way for the developer to get things started.
2. A shorter name. If we support end users, this tool probably will end up as a top 3 tool that the user needs in their daily life in the certain countries. Running shapeshifter-dispatcher command frequently isn't convenient. I'd recommend we drop it to 3 letters, for example ptd, standards for Pluggable Transport Dispatcher.

What we need in this issue is the decision for the direction? Below are possible options:

1. Keep what this project is, and keep it close to the specification. Other project can folk this project for inspiration.
2. Keep the small scope, but are open to refactoring, so this project can be a building block for other projects. Other project can import/extend this project.
3. Keep backward compatibility as top priority but open for new feature requests mentioned above.
4. Free to pivot. If we can show the value to end users, why not? backward compatibility is not a must, but a wish.