For (1) and (2), it sounds like you already have the solution planned out. Desk.com integrates the knowledge base functionality with the support system by default, and exposes answers (that you control) to your website with some basic integration. You can read more about that here.
For (3), there are a few things to consider. First, most developers have grown accustomed to basic API/SDK documentation standards, and there is really no good reason to deviate from those. Both Javadoc and phpDocumentor are capable of generating familiar, browse-able documentation, so make sure your developers include the proper documentation in their code, and then auto-generate new API docs with each release. There is no substitute for this kind of clear, commonly-formatted API documentation.
Were it up to me, you really don't want your users contributing to the documentation itself, but rather contributing things like code samples, "cookbooks", and that sort of thing. If you find that your users need to augment the API documentation itself, chances are your documentation is lacking somehow.
As for a tool to do this, as you suggested a Wiki is often the best way to go. MediaWiki is good in that most people know how to use it, but for a more professional looking and easy-to-use software, I'd suggest Confluence from Atlassian. The downside is that this is a much more expensive option; Confluence is priced more for internal use and can be costly to deploy in an unlimited-user situation. There are other options out there as well that may strike a balance between these two.
Finally, it is likely that your users will find issues with your API, create workarounds, develop really cool add-ons, and so on. It is important to manage your user-contributed works in such a way that these facts are tied to specific versions of your software, since as your company hopefully grows, you will eventually have many versions and many users of each version. When you do deploy documentation and/or a collaborative tool, make sure you can easily segregate content by release version. It's also a good idea to expose some or all of your defect tracking solution to end users, both to help them understand what is in progress, and to leverage them as a global QA resource.