Rename data layer specialization functions to match QuTiP conventions

[hodgestar]

Currently the specialization functions are named, e.g., cpd_add. Existing QuTiP data layer specializations are named with the function name first, e.g. add_dense.

We should rename the CuPy specializations to, e.g., add_cupydense.

[jakelishman]

Just for clarity, the naming scheme I used is:

• if all operands and outputs are of the same type, then the name is <opname>_<typename>
• if any operand or output is unequal to the others, then the name is <opname>_<input_typename_1>_<input_typename_2>_[...]_<output_typename>

In general, these don't actually matter too much, because they're largely not intended for direct public use - you can just query the dispatcher object to get the correct specialisation. It mattered more for the two core classes, which also need to be able to be used from Cython, where the full dispatcher mechanisms are bypassed.

[MrRobot2211]

Is there any reason for the specialized construstors not to be named <constructor>_<typename>? E.g. diags_Dense

[hodgestar]

Is there any reason for the specialized construstors not to be named <constructor>_<typename>?

diags_cupydense looks good to me -- let's use the convention everywhere.

[jakelishman]

As much as there is one, the reason they didn't have it was because in my first pass at writing things, the constructors weren't exposed outside of Cython, and they'd be accessed with qualified access by csr.diags or dense.empty, etc; they used proper namespacing rather than "C namespacing", since they weren't really going to be called by the same functions. With multiple dispatch, the single namespacing like that no longer makes sense.

[MrRobot2211]

This has been tackled in #10 . I am closing this one an opening one in QuTiP to change names.