document DLL updates

[barbeque-squared]

this PR tries to capture what was written in this comment: #889 (comment)
in a way that I (or anyone) can find this back a year from now

most notably

• I merged steps 5 and 6 into a single step, because from how I understand it, we should make the pre-release pretty much as we merge the USDX PR? all the previous steps can have some time between them and it won't break anything
• I made step 7 into its own little section as that is something that isn't really connected to the original updates anymore. You're also doing it as part of releasing USDX itself, so it is a little bit more verbose. I'm not sure if it's 100% correct because we've never done that, but it's better than nothing.

@s09bQ5 the thing I'm most unsure of is when exactly to "Release updated DLLs". Currently it's before you touch anything USDX-related, but should it be between step 5 and 6 of RELEASING.md instead?

[s09bQ5]

Looks good

The "Releasing updated DLLs" step isn't really necessary because the dldlls.py script doesn't care about the name of the release. I would do it between step 2 and 3 of RELEASING.md. That way the release build would already use the renamed dll release.

[s09bQ5]

If we merge without merge commit (i.e. enable 'Require linear history' for the master branch and use rebase merging), there is no need for step 4 unless the PR really needs a rebase.

[barbeque-squared]

As long as the PR submitter allows maintainers to edit, we should be able to do the commitid update through the webinterface. I'd rather keep all repo's setup the same.

Putting it between steps 2 and 3 is a good idea, I'll update the PR later today.

[barbeque-squared]

Didn't get around to it yesterday, but it's updated now. I will try and get a release out in the second half of september (probably the weekend of Sep 21).