Define fail modes for `.T`/`.transpose()`

[flying-sheep]

Transposing operations need to work or fail with a good message.

• backed=True and .raw should be supported by some view-like method
• If the AnnData object has alternative .modes (upcoming feature), .T should throw a warning or error that the modes are lost, .transpose should gain a lose_modes=False parameter that avoids the error by explicitly opting into losing the modes

@ivirshup mentioned that he doesn’t like transpose for those bugs: https://github.com/theislab/anndata/issues/237#issuecomment-551409000

[ivirshup]

Also: https://github.com/theislab/anndata/issues/225

• Raw is supposed to share obs with the parent object. Transpose with raw should probably fail if the raw var_names doesn't match the parent. However, what's the point of raw if it has to shares both obs_names and var_names?

If the AnnData object has alternative .modes (upcoming feature), .T should throw a warning or error that the modes are lost

Are there fewer arrays in the output here? Which ones are removed, which are kept?

---

And a general question, is transpose a valuable operation to have for the entire object? What's the use case?

[LuckyMD]

adata.raw is still useful if it has the same dimensions as adata.X as it is used for statistical testing by default. Therefore you can use it to start log-normalized data, when adata.X has (e.g., batch-) corrected and maybe scaled data. I guess with sc.pp.highly_variable now annotating genes rather than filtering them adata.raw is often the same dimensions as adata.X now. I reckon it could therefore be slowly deprecated...