Document upgrade order for tribe and CCS

This is one area that is not covered today in our docs today.

Even though tribe is deprecated, it is still in the product on 6.x. There will be questions around upgrading tribe node implementations for those who are not ready to switch to CCS yet. Afaik, they need to upgrade the tribe to 6.0 first before the downstream clusters because if the tribe remains on 5.x, it will not be able to join any downstream clusters that have indices created on 6.0. For example, can they upgrade tribe to 6.0 first and then do rolling restarts of downstream 5.6 clusters to 6.0? This is something we will have to sync up with dev on our recommendations. This will probably depend on the outcome of https://github.com/elastic/stack-docs/issues/17, but I do want to make sure that the results are documented :)

Note that some customers may resist switching to CCS right away because, eg.

- CCS will require that they make changes to their application (not an issue if they use Kibana, but if they don't, then app changes will be needed to use the new CCS syntax).
- Some customers are more comfortable waiting for a new GA-ed feature to bake in before deploying to production.
- Or that they need to upgrade to 6.0 to take advantage of some other new features, and prefer to tackle the tribe node piece later

So if we decide that we will not be testing/supporting tribe for rolling upgrades because the tribe node is deprecated, we will just have to document it to set the right expectations upfront.

Even for CCS, there will be questions on upgrade ordering (upgrade CCS first? Downstream clusters?).