Mitsuba plugin family Field for texture/neural storage & encoding

[ziyi-zhang]

Description

Introduces Mitsuba's render-layer Field plugin family: a common storage, Dr.Jit encoding, and neural-query abstraction for texture/volume-backed data, learned fields, radiance caches and neural BSDFs while preserving existing texture and volume public APIs.

1. This PR is not as big as it seems. Most edits are mechnical.
2. Many design choices were made 2 months ago from old discussions with Wenzel, Christian, etc. When I reviewed them again this week, some of them are quite restrictive -- if we want to change any design, happy to change!

Key design decisions:

• One plugin category, no wrappers. All data-source plugins report ObjectType::Field;
  <texture> and <volume> only validate the requested use and return the same object. This
  preserves identity, traversal keys, and AD connectivity.

• Intentional Python API change. mi.Texture, mi.Volume, and register_texture()
  are replaced by mi.Field, mi.FieldPtr, and register_field(). XML remains compatible;
  C++ aliases remain as migration aids.

• Conservative volume support. Generic Fields may satisfy the surface role. Volume use
  requires VolumeField because renderers depend on trusted bounds, transforms, majorants,
  and channel metadata.

• Generic and optimized evaluation coexist. Dynamic evaluation supports arbitrary
  outputs and optional borrowed argument channels; fixed-size methods remain available for
  hot renderer paths. Existing texture/volume consumers require args_dim == 0.

• Explicit neural limits. Neural Spectrum output is rejected in spectral variants
  because the decoder is not wavelength-conditioned. neuralbsdf remains diffuse so eval,
  sample, and pdf stay consistent.

[merlinND]

Small note, what is the plan for the naming conflict with the existing field<T1, T2> struct? (I didn't read this PR's diff)

mitsuba3/include/mitsuba/core/field.h

Lines 39 to 41 in 4bf6f10

	template <typename DeviceType, typename HostType>
	struct field<DeviceType, HostType,
	dr::enable_if_t<std::is_same_v<DeviceType, HostType>>> {

[ziyi-zhang]

Small note, what is the plan for the naming conflict with the existing field<T1, T2> struct? (I didn't read this PR's diff)

mitsuba3/include/mitsuba/core/field.h

Lines 39 to 41 in 4bf6f10

	template <typename DeviceType, typename HostType>
	struct field<DeviceType, HostType,
	dr::enable_if_t<std::is_same_v<DeviceType, HostType>>> {

From Wenzel:
For field<T>, how about sync<T> (preferred if available) or replicate<T>?

EDIT: This has been changed to synced<T>.

[merlinND]

To me sync<T> sounds a bit too similar to dr.sync_thread().
How about synced<T>, synced_v<T> or synced_value<T>?

If we want something very short, we could also go for rep<T> (short for replicate and similar to ref<T>).