create API for tstop aliasing system

[isaacsas]

Per discussions @ChrisRackauckas and I had around SciML/JumpProcesses.jl#442 it would be nice to be able to have users tell us we can alias their tstops vector in JumpProcesses so we don't need to allocate a new vector for each call to solve.

[ChrisRackauckas]

My plan is to create a keyword argument alias which then has a struct ODEAliases <: AbstractAliasSpecifier etc., that holds booleans/nothing for each thing that can be aliased. nothing for default behavior, true/false for forced aliasing, de-aliasing. This can then be rolled out for every problem type uniformly, and include booleans to cover the keyword arguments.

[ChrisRackauckas]

@jClugstor does this specification make sense?

[ChrisRackauckas]

You'll find:

alias_u0: allows the solver to alias the initial condition array that is contained in the problem struct. Defaults to false.

in DiffEq

alias_A::Bool: Whether to alias the matrix A or use a copy by default. When true, algorithms like LU-factorization can be faster by reusing the memory via lu!, but care must be taken as the original input will be modified. Default is true if the algorithm is known not to modify A, otherwise is false.
alias_b::Bool: Whether to alias the matrix b or use a copy by default. When true, algorithms can write and change b upon usage. Care must be taken as the original input will be modified. Default is true if the algorithm is known not to modify b, otherwise false.

in LinearSolve. Etc. All of that should get folded into just these more general structs, and the old way should get deprecated to just setting values of the struct.

[jClugstor]

I think I get it. alias should be a keyword of ODEProblem, LinearProblem, etc. that would be of type e.g. ODEAliases and LinearAliases respectively. And each concrete subtype of AbstractAliasSpecifier should hold boolean values that correspond to the parts of their corresponding problems that can be aliased.

[ChrisRackauckas]

Yes exactly.

[jClugstor]

Should the types ODEAliases and LinearAliases etc. be defined in SciMLBase?

[ChrisRackauckas]

yes

[jClugstor]

I'm thinking that the problem types will need a new field to hold the AbstractAliasSpecifiers, does that sound right?

[ChrisRackauckas]

I don't think so, they will just be a new common kwarg to solve.