Unit tests for FVGQ first order underlying gradient objects

[jlperla]

• [ ] In the old code we should come up with 2ish nonzeros for each of the objects in the gradient calculations for a unit test
  • Basically the stuff in https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl/blob/main/src/types.jl#L184-L201 with a _p on it. We can save out those values
• [ ] In the new code, we can then just add all of those into https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl/blob/main/test/FVGQ20.jl

If that passes, at least we know that the underlying calculations aren't broken.

We should be very careful to ensure we don't let floating point calculations be loose for this. It should be very close.

[jlperla]

118 This will fulfill it largely. We can keep it open temporarily because with FVGQ it might be necessary to see where the issues arise.

[jlperla]

@wupeifan Save out c.h_x_p and c.g_x_p from the old code for the gradient wrt only the beta parameter. I think all we really need to do is have the c.h_x_p to see if things changed. If it did, it gives us a target to find the discrepancy and we can get fancier with unit tests after we fix the problem. If these values are the same as the current (buggy) code then it leads us down a different path.

When we have those values, add it to the unit test hardcoded in https://github.com/HighDimensionalEconLab/DifferentiableStateSpaceModels.jl/blob/main/test/FVGQ20.jl#L112

But like I said, I think all we really need is the c.h_x_p for the beta one for now.

[jlperla]

Unit tests now passing for gradients