Add a draft of code insights docs pages [Discussion]

Created by: Joelkw

The catalyst for this was @nicksnyder's slack message here.

I'm putting up this draft PR for discussion rather than as evidence of WIP (though it contains a WIP we can take next steps on depending on the discussion). In starting this, two questions came up that I think we should align on before continuing down this path.

Questions for @nicksnyder or @felixfbecker, with my answers inline below. You're welcome to leave a full response or just a quick topline "I think we should do it / I think we should wait"

• Does it make sense to start adding code insights documentation to our official docs?

I don't think so. While we have "documentation", this is not final (the ultimate code insights UI won't be in settings like this) nor is the code insights product quite at a level of "self-discovery." By that I mean that we don't have a working backend – so your average code insight attempt will just timeout if you use it on a lot of your code – and a user is likely to get frustrated with the feature, and less likely to try in the future, if they discover it on their own rather than with the high-touch expectation-setting of a CE or PM. We are intentionally keeping code insights less discoverable until it enters a "beta:" roughly -- working backend, v1 UI, clear what it does and works for the primary use cases.

But, if you think we should add it to docs:

• How do we best communicate that insights are still very much a prototype? Can we leave it out of the sidebar (make it less discoverable to a "browsing" user)?

We can add some quick treatment to the basic [Prototype] labels I have in the title as well. Are there other things we've done int he past? I would prefer to leave it out of the sidebar until it's a beta for the same reasoning in the prior answer.

Other considerationsIthat would convince me this is a good idea to do now: this would help us with hiring; this would let us capture insights as we build it (at the moment, though, the work is backend and the documention is more oriented towards a Sourcegraph engineer than a user).

This update is a failure if: it makes people annoyed that code insights doesn't work even if it's in the docs, or if people try it, see that there isn't much there yet, and decide not to return to using code insights when it actually launches.

This update is a success if: it gets people excited about code insights and creates an active inbound feedback pipeline. I think this is entirely possible, but I would prefer to wait until we reach our "beta" milestone (to paraphrase from the goals, this means it has a UI, scales to all repos, and is primarily supported by the CE team. We've reached none of these points yet, though we should get to the backend one by 3.25)