Enhance consistency of the code regarding `T_A` and `T_B`

[NimaSarajpoor]

It seems there are a few inconsistencies in the naming of variables and the way they are being passed to functions.

(i) In stump, we have this:
https://github.com/TDAmeritrade/stumpy/blob/f078424350ab97d02a517da9e29b254309b27574/stumpy/stump.py#L634-L650

So, T_A corresponds to Q-related variables, and T_B corresponds to T-related variables. However, we see something different in gpu_stump:
https://github.com/TDAmeritrade/stumpy/blob/f078424350ab97d02a517da9e29b254309b27574/stumpy/gpu_stump.py#L577-L578

(ii) Also, the module stump itself shows some sort of inconsistency:
https://github.com/TDAmeritrade/stumpy/blob/f078424350ab97d02a517da9e29b254309b27574/stumpy/stump.py#L678-L695

Since we pass the arguments as _stump(T_A, T_B, ...), we should expect to see the same order in the rest of the arguments. However, this is not true here. As you may have noticed already, M_T (which corresponds to T_B) is located before μ_Q (which corresponds to T_A).

---

In my opinion, these inconsistencies occur because we, unintentionally, confuse ourselves by using the T_A, T_B naming and Q and T naming. I think we should usually consider T_A as the sequence that contains queries (hence Q), and T_B is T.

So, if we do:

Q, μ_Q, σ_Q = core.preprocess(T_A, m)
T, M_T, Σ_T = core.preprocess(T_B, m) 

We will be consistent and we will not be confused when we try to be consistent regarding the order of arguments in a function.
(Btw, I just provided two examples. I haven't checked all modules yet)

[seanlaw]

Sounds good! That makes sense and I am in agreement that T_A should always correspond to Q and, vice verse, with T_B and T. Although, I wonder if it is confusing when we have functions that only take T and m but no Q? In that case, T has no direct relation to T_B

[NimaSarajpoor]

Although, I wonder if it is confusing when we have functions that only take T and m but no Q? In that case, T has no direct relation to T_B

I didn't get it before...but I think I see your point now when you talked about functions that take T but no Q. So, as you explained, we should better keep T_A and T_B not just in public API but throughout the code.