Add support for J2 plasticity

[Rombur]

This is still a work in progress. The first two commits could be moved to their own PRs but they are literally one line each so I don't think it matters.
Things left to do:

• Decide where the new code should go. I've put it in MechanicalPhysics but we could put it in MechanicalOperator. My reasoning is that, the new code does not need "solving" but I don't know where is the right place.
• The code does not work if the mesh is refined or material is added.
• Testing. I tried to find analytical solutions on internet but I couldn't find anything. Usually people just do comparisons with commercial software but the models are slightly different and the results don't match. If I could get help with that, it would be fantastic.

[stvdwtt]

Great!

Re where it goes: I'll read it through let you know if I have any thoughts/preferences.

Re testing: This is mostly a note for myself. Verification Test 1 mentioned here might be of use, but I need to read through it in more detail.
https://csm.mech.utah.edu/content/wp-content/uploads/2011/10/9tutorialOnJ2Plasticity.pdf

[Rombur]

Analytical solution on sphere and cyclinder:

• https://doi.org/10.1016/0308-0161(94)90096-5
• https://doi.org/10.1016/0308-0161(93)90004-D

Possible code comparison:

• felupe: see tutorial

[Rombur]

This PR should actually work if you add material in serial. I need to check that it works properly though.

[Rombur]

I think this is PR should be good enough for what Ayana needs (ie we can add material in serial but not use AMR). Of course, we still don't have good tests so that's pretty annoying.

[stvdwtt]

@Rombur, sounds good. I'll review and merge as soon as possible. The test case for Ayana will at least give us a sanity check until we have good tests in place.

[stvdwtt]

This looks great. I have just a few minor suggestions for edits/additions of comments and changes to variable names.

[stvdwtt]

I'd suggest using plastic_strain_increment instead of plastic_strain since $\Delta \lambda$ corresponds to only the extra increment of plastic strain during the time step, not the total plastic strain.

Suggested change

	double plastic_strain =
	double plastic_strain_increment =

[stvdwtt]

Calling it a normalized effective stress is accurate, but physically it's a the direction of plastic flow. I suggested changing it to something like:

Suggested change

	auto normalized_effective_stress =
	auto plastic_flow_direction =

to clarify how it should be interpreted.

[stvdwtt]

I think "The displacement is ignored." might be more accurate than "The displacement is zero.", since the displacement being zero could be interpreted as enforcing a rigid boundary for the solid material.

[stvdwtt]

Consider putting here or elsewhere a brief mention of the reference. I know in my work it can be helpful to know where I got the formulation from a few months or years down the line.

Suggested change

	// Compute the strain. We get the strain for all the quadrature points at
	// Formulation based on the combined isotropic-kinematic hardening
	// model for J2 plasticity in Chapter 3 of R. Borja, Plasticity: Modeling
	// and Computation, Springer-Verlag, 2013.
	// DOI: 10.1007/978-3-642-38547-6
	// Compute the strain. We get the strain for all the quadrature points at

[stvdwtt]

@Rombur There was a repeated phrase in one of the comments (I think probably due to how I structured the "suggested edit"). I went ahead and fixed that directly. Once the CI passes I'll merge this in.

[Rombur]

There was a failure (see here). I have seen this a couple of times. Usually re-running fixes the issue. I don't know where the problem comes from. I have run the test in valgrind and everything looks fine.

[Rombur]

The CI passed, so we can merge this.

@stvdwtt where do you think the new code should go? MechanicalPhysics, MechanicalOperator, or a new Operator? I can move the code in a different PR if we think it would be better somewhere else.

[stvdwtt]

Merging it now. I think it works well in MechanicalPhysics, at least for now. If we get to a point where we have a more complicated model or options between models, it might make sense to move it to a new operator. But I don't have a good enough sense of where we're going with this next to justify a particular structure.