Make state setting easier through builder pattern

[NicEastvillage]

I noticed that state setting is a pain in Rust due to all the Options. This API makes it easy to set the fields that you want to change without thinking about all the optionals.

Example:

let mut dgs = DesiredGameState::default();
dgs.mod_car(0, |c| {
    c.set_location(Vector3::default());
    c.set_boost(100.);
});
dgs.mod_balls(0..5, |_, b| {
    b.set_location_z(0.);
    b.set_velocity_z(0.);
});

[swz-git]

General questions:

• How are the ergonomics of passing functions instead of DesiredXState directly? Is it worth not being able to pass already built DesiredXState?
• Maybe all of the builders should take a mutable reference in ::new()? Or maybe none of them should? Is the inconsistency worth it? (see below)

Currently the ergonomics seem to be adapted for use-cases like your example in the docs. But what about if you want to set a Vec of already existing DesiredCarStates? See comment on all_cars.

[swz-git]

Perhaps a better solution would look like this? What if you want to state-set only balls 0 and 2 for example. This applies to all_cars too.

Suggested change

	/// Modify all desired balls.
	pub fn all_balls(
	mut self,
	range: Range<usize>,
	build: impl Fn(usize, DesiredBallBuilder) -> DesiredBallBuilder,
	) -> Self {
	while self.state.ball_states.len() < range.end {
	self.state.ball_states.push(Default::default());
	}
	for (i, ball) in self.state.ball_states[range].iter_mut().enumerate() {
	build(i, DesiredBallBuilder::new(ball));
	}
	self
	}
	/// Modify all desired balls.
	pub fn all_balls(mut self, build: impl IntoIterator<Item = (usize, DesiredBallState)>) -> Self {
	for (i, ball) in build.into_iter() {
	if self.state.ball_states.len() <= i {
	self.state.ball_states.resize(i + 1, Default::default());
	}
	self.state.ball_states[i] = ball;
	}
	self
	}

[NicEastvillage]

If you only state-set ball 0 and 2, then you should probably use the ball method twice instead. Changing range to impl IntoIterator<Item = usize> is a good idea though.

Regarding passing in DesiredXState instead of functions - If you already have an iterator of DesiredXState, then the normal API is not hard to use.

[NicEastvillage]

Stuff changed in 7f7835e