Merge upstream changes, and add instructions on how to do that

[shrouxm]

@tjdevries

The git steps are simple enough that I feel like just having a doc instead of a script would be less error prone and easier to understand, does that sound good to you? Also does storing the latest LLVM commit on the clangd branches in just a text file at the root seem too janky? Did neovim have a nicer way to keep track of that metadata?

[tjdevries]

One thing I don't understand is that now that we're merging in 10.0.1 into this branch, shouldn't we make a new branch on our end for llvmorg-10.0.1-clangd or something. I'm a bit worried about getting the histories messed up

[shrouxm]

@tjdevries hmm, yeah, that is confusing. i don't think we need separate branches for different minor versions, but the name of this branch is now inaccurate. i'm not actually sure we need different branches for major versions, but i think it helps git figure out how to make the merges clean? or maybe we can just have a main branch and a clangd branch and use tags to differentiate? at this point i think this PR is just a model to show how merging upstream changes would work but i'm not sure exactly how to structure it.

this repo setup is stretching my git knowledge tbh so i'm super open to suggestions to how to structure the branches, but i'll try to take stock tomorrow and make a proposal.

[tjdevries]

I can do some research on how people are doing this and do an RFC for it :) It would be good practice for me (even if it only ends up being me & you doing the RFC haha)

[shrouxm]

We ended up doing this via a different strategy.