Remove Stan fit files from tests

[seantalts]

Copying the goals from discussion on stan-dev/stanc3#409,

Hmm. I think we could formulate these [tests in test/integration/tfp] as cram tests (aka gold tests, or expect tests in OCaml). Then we can have a way to automatically generate the correct values from Stan and an automated test of the TFP backend against those values. How does that sound?

I don't want to be prescriptive here - I think some goals in maybe descending order of preference from my perspective would be:

1. Easy to understand what is being tested and what is going wrong when a test failure occurs
2. Easy to create new tests or update the tested values when something changes (though these are testing end-to-end stuff that isn't supposed to change except for bug fixes and major version number bumps)
3. Has a small footprint
4. Separates code requiring the Stan toolchain from code requiring the TFP toolchain (not a huge priority but could be nice to have)

So it's possible that the best solutions to 1 and 2 have a larger footprint and that's okay, we can just organize around it.

[bob-carpenter]

We've already polluted our math lib code with the Apache 2 license for the Intel TBB, so dependencies to TFP should be OK as long as they're stable. It'd be nice if we don't have to update anyhting other than the TFP generator.

[adamhaber]

Resurfacing this. The current TFP integration tests are not ideal (see the discussions on stan-dev/stanc3#409 and stan-dev/stanc3#388 ), and I'd like to improve them. Specifically, removing the Stan fit files and automating the log_prob comparison would be great. Would be happy to hear your thoughts on this.

A question in this regard - given a .stan file that has K parameters, can we compute the lp__ of N predefined vectors in R^K (unconstrained) during testing?