Way back when the Djblets API code was written, we disabled caching

headers across the whole API. This was a holdover from the

implementation we brought over from Review Board, and was due to working

around what was at the time a caching bug with IE (back in 2007 --

Review Board commit c5893693b7).
Since then, we'd introduced various levels of caching support throughout

the APIs, and no longer needed to never-cache by default. Still, some

API endpoints had this applied.
Some earlier versions of Django (certainly 1.6, and I think 1.11 in

cases) removed the never-cache headers when we set new caching headers,

but Django 3.2 certainly does not. This means that some API endpoints,

including /api/, are never cached, increasing response times

unnecessarily.
This change removes this never-caching, allowing normal cache headers to

be set by default, and enabling our API endpoints to fully manage their

own caching.
This shouln't cause regressions, but it's always possible something may

break unexpectedly. The correct solution then would be to have API

endpoints dictate that they don't want their contents cached.

Unit tests pass in Djblets and Review Board.
Verified that affected API resources now show the expected caching

headers.