Remove resume_from and default_chain_type

[penelopeysm]

Removes resume_from=chn, replaces with initial_state=loadstate(chn).

Also removes default_chain_type. The reason why I want to do this is because it's one step towards removing Sampler. The replacement for this is to specify a default chain type in Turing rather than in DynamicPPL. I'll do that in a separate PR. (Notice that the default chain type is MCMCChains.Chains, but MCMCChains isn't a dep of DynamicPPL. So it just makes more sense to define this in Turing anyway.)

Closes TuringLang/Turing.jl#2675
Closes TuringLang/Turing.jl#2171
Closes #1049

[github-actions]

DynamicPPL.jl documentation for PR #1061 is available at:
https://TuringLang.github.io/DynamicPPL.jl/previews/PR1061/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.38%. Comparing base (08212a2) to head (c672e3a).
⚠️ Report is 1 commits behind head on breaking.

Additional details and impacted files

@@             Coverage Diff              @@
##           breaking    #1061      +/-   ##
============================================
- Coverage     82.39%   82.38%   -0.01%     
============================================
  Files            42       42              
  Lines          3818     3816       -2     
============================================
- Hits           3146     3144       -2     
  Misses          672      672              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sunxd3]

looks good

one tiny concern is whether this really closes #1049: I assume
https://github.com/TuringLang/DynamicPPL.jl/blob/c672e3adecf6e6409decd55bd1cdad90631c65ed/ext/DynamicPPLMCMCChainsExt.jl#L15C12-L15C37 does the right things for different kind of chains, but I thought it's worth mentioning.

[penelopeysm]

Thanks @sunxd3! Yeah, that's fair. loadstate only works directly if the saved chain 'matches' the resuming chain in terms of the number of chains. My current thinking is that it's OK to not extend the interface, and instead document the format that it returns / the format that the next chain expects so that users can manipulate it themselves into the right format if needed - do you think that'd be alright? The documentation in this PR TuringLang/docs#654 :)

[penelopeysm]

Docs are now live here https://turinglang.org/docs/usage/sampling-options/#saving-and-resuming-sampling

[sunxd3]

@penelopeysm sorry for missing this -- looks good! thanks