Add RayTraceConfigurationBuilder

[notTamion]

closes #9942
pre hardfork #10237

Make sure to look at my last comment on the old pre hardfork PR (i still think this is the case)

[lynxplay]

Just to make sure I recall the previous design correctly, the idea was that the builder itself contained executing methods and allowed configuration of starting position and direction vector right?

I still do not believe it is a good design choice to have execution methods on the builder/executor type itself, specifically when it itself just calls back to the world. We could however move starting position and direction vector onto the builder too (e.g. in the factory method) and then also expose a wither method on the configuration itself so people can easily update it?

E.g.

final var config = RayTraceConfiguration.builder()
  .direction(dir).origin(pos)
  .target(BLOCKS);
world.rayTrace(config);
world.rayTrace(config.relocate(pos, dir));

Just an idea tho, would love your input on that.

[notTamion]

We could however move starting position and direction vector onto the builder too (e.g. in the factory method) and then also expose a wither method on the configuration itself so people can easily update it?

Doesn't that just defeat the purpose of having an immutable configuration?

Unrelated I just think that having a configuration for this just doesn't really work out. The adventure JoinConfiguration (which was used as an example in previous discussions) only defines a format. though here we would basically be defining the values in the configuration. (can't really find a better analogy)

Might be worth having some more people in the community give feedback on what they prefer as i am sure that personal preference is playing a big part here.

[lynxplay]

Well that was your issue in the last comment on the pre-hardfork PR tho right?
The fact that consumers need to pass location and direction on each invocation.

The configuration would still be immutable, consumers that ray trace the exact same configuration would be fine and consumers that ray trace the exact "configuration" but from a different location/direction would only have the performance downsides of a single record copy.

This problem however isn't even solved with the previous approach discussed.
The only difference being that the previous approach was completely mutable and took over the responsibility of casting a ray. But yea I agree, more input is definitely needed.