Refactor cache

[lijas]

This is how I think material cache should be implemented.
I once implemented a material that needed to store 2 vectors, and I think the current implementation of caches does to allow for that...

So now each material that needs cache, can wrap their vectors etc in their own type.

I had to refactor the planestress-wrapper aswell.

[kimauth]

I think I would separate the two types of cache that we need at the moment completely. That is, have one SolverCache (the OnceDifferentiable for now) and one PlaneStressCache that only stores the fields for plane stress iterations (but not the SolverCache. Then we could have different constructors, e.g.

cache1 = get_cache(::Material) # the OnceDifferentiable
cache2 = get_cache(::Material, ::PlaneStress) # a wrapper type with OnceDifferentiable and PlaneStressCache as fields
cache3 = get_cache(::Material, ::PlaneStrain) # only OnceDifferentiable again

and access their fields via accessor functions, e.g.

get_solver_cache(c::OnceDifferentiable) = c
get_solver_cache(c::CacheWrapper) = c.nlsolve_cache
get_plane_stress_cache(c::CacheWrapper) = c.plane_stress_cache

[lijas]

It the advanced material mechanics course I need a costum chache since i am not using nlsolve.

struct Plastic2Cache <: MaterialModels.AbstractCache
    x::Vector{Float64}
    R::Vector{Float64}
    J::Matrix{Float64}
end

Is it ok if I merge this (after some cleanup) since #44 removed the need for cache plane stress iterations?

[kimauth]

I usually prefer being explicit with the return statements (and I think we pretty much are in the rest of the package).

[kimauth]

I think this could be NLsolveCache and live in a seperate cache.jl file. It is not really specific to the plastic material at all, rather applies to any material that would use nlsolve as a non-linear solver.