Add option to skip tracking for entities out of client render range

[NewwindServer]

The client uses a built in heuristic to decide whether an entity should be rendered, completely independent of tracking range:

view scale = clamp(server render distance / 8, 1.0, 2.5) x entity distance scaling (controlled in client settings, almost always the default, 1.0)
entity render distance = 64 * bounding box size * view scale

Currently, the server still tracks these entities and sends packets about then despite them not being rendered by the client, this is especially noticeable for item entities due to their small bounding box size:

item entities on a server with 8 view distance will only render from 16 blocks away despite it being tracked from 96 blocks flat distance away by default (misc category)

This PR fixes that by adding the option to skip tracking entities that would be out of render range for clients, since we can't know what distance scaling the clients have set, there is also an option to set a custom one, although it is almost always set to 100% (the default)

[NewwindServer]

One small caveat I have noticed, shouldRenderAtSqrDistance is overridden in quite a few ways, for example in WindCharge:

@Override
	public boolean shouldRenderAtSqrDistance(double d) {
		return this.tickCount < 2 && d < MIN_CAMERA_DISTANCE_SQUARED ? false : super.shouldRenderAtSqrDistance(d);
	}

since it decides not to render if it has a tick count under 2, with network latency and the option enabled spawning a wind charge makes it not appear for a few ticks on the client's screen. This could easily be fixed by having a minimum distance before doing these checks but ehh...

[NewwindServer]

Video showing the issue that this PR fixes of various entities not being rendered but its hitbox still being visible (still tracked)
https://github.com/user-attachments/assets/e2f3c871-b197-42dc-8b00-9af15f9421e9

[lynxplay]

I am a little worried about this config option, that path is already very hot.
Additionally, as you pointed out already, the "heuristic" defined there is less of a heuristic and very much also include gameplay features, like some projectiles rendering 2 ticks later after spawning.

Given the tick count is not synced with the client when pairing, we'd basically be doubling that even without any network delay.

Beyond that, there is also the RemotePlayer trouble, which first expands the bounding box of the player by 10.
That class is not even shipped on the server and now our heuristic is completely inaccurate as we'd be using the Entity one (which is too low in size) to hide a player that the client would render.