Example code mutates a ParticleFilterState directly, but ParticleFilterState is undocumented

[bzinberg]

From #49 (comment):

we should not be mutating the (undocumented) traces field of the (undocumented) ParticleFilterState struct. The reader should (unlike I did) know what their rejuvenation move is supposed to do, but they shouldn't be responsible for knowing what representation invariants a ParticleFilterState has to satisfy, i.e., whether direct mutation (in Julia, outside Gen) is allowed, and if so, what other fields need to be updated simultaneously to maintain data integrity.

In the Gen documentation, particle filter states are treated as black boxes that can only be looked under the hood via Gen APIs. So I think for rejuvenation moves we should either make an API, or document the representation invariants that someone who mutates a ParticleFilterState should maintain.

[ztangent]

I've been directly mutating ParticleFilterState for some custom SMC code I'm writing too -- I'm in favor of just documenting ParticleFilterState, because there are a lot of other things you might want to do with a particle filter, including custom rejuvenation moves, but also custom initializations (e.g. stratified sampling from the prior so you have low variance even w a small number of particles) and custom resampling steps (e.g. stratified resampling, etc., for the same variance reduction purposes).