Update Fan Cases with mention of the Pi 4 Case Fan

[nllho]

Resolves #3566.

Keeping it minimal here! My thinking (for these types of tickets in general) is that if the current/latest model is already documented, we only need to include previous models for completeness. That means that we won't have the finer details of Pi 4 fan behaviour in the doc (at least until there's a good use case to go around and dig them up!) The assembly and usage instructions for both fans can be found on their respective product pages and product briefs.

Other notes (just general tech writing thoughts):

• Since I chose to keep the Pi 4 fan mention quite short, I didn't create a new section for it.
• I put the mention at the top of the Fan Cases section, rather than at the bottom. That particular section ends with a table, and in general I'll avoid placing short pieces of information right below tables or graphics, since that makes them somewhat easy to miss.
• I made some small readability updates to reinforce the fact that the detailed information refers to the Pi 5 fan only.

[nathan-contino]

Nice improvement. Your additions made me think a little more critically about the section layout, so I made some suggestions. Address my nitpicky suggestions and we'll merge this in!

[nathan-contino]

lgtm!

[nllho]

Thanks so much @nathan-contino! The nits are very helpful, especially early on -- I can start to see how much editing and rewriting we want to aim for in these types of PRs.

Have reviewed the style guide (and will reread it often, I'm sure). For future issues, in addition to making changes addressed in the issue, I'll think about style and structure edits at roughly the same "level" as you're suggesting here :)

[nllho]

One more nit 😁 Thoughts on this header? It's at the same level as the other "fan" headers (I didn't want to make it too small). Normally I don't think I would separate this information out using a header, but in this case, the connector info is linked in the introduction.

[nathan-contino]

Seems like a reasonable compromise. Ideally we'd nest this within the Pi 5 section, but... that might go too deep. This seems to be the best place for this right now.