VisualObject: do not include MRVector.h, MRMeshTexture.h and MRIRenderObject.h

[Fedr]

MRVisualObject.h stops including MRVector.h, MRMeshTexture.h and MRIRenderObject.h. It mentions neither Vector nor MeshTexture at all, and needs IRenderObject and the render-param structs only for a member and for by-reference parameters, so those are forward-declared in MRMeshFwd.h instead.

VisualObjects move constructor, protected copy constructor, move assignment and destructor move out of line. This is what makes the incomplete IRenderObject acceptable: MRMESH_CLASS is __declspec(dllexport) while building MRMesh, and MSVC emits every defaulted special member of a dllexported class, which instantiates unique_ptr<IRenderObject>::~unique_ptr and static-asserts on the incomplete type. It is not specific to MRUniquePtr.h - a plain std::unique_ptr<Incomplete> member behaves identically; a 25-line repro compiles with dllimport and fails with dllexport, and passes again once the special members are declared out of line.

The files that were relying on the transitive includes now include what they use:

• MRIRenderObject.h in the 16 files calling createRenderObject() or dereferencing renderObj_, plus MRRenderWrapObject.h;
• MRVector.h in the two headers with a VertColors member;
• MRMeshTexture.h in the four files using MeshTexture;
• MRHeapBytes.h in 22 files that call MR::heapBytes() in inline bodies and were getting it via MRMeshTexture.h -> MRImage.h;
• <typeindex> in MRVisualObject.h itself, for the std::type_index member of AnyVisualizeMaskEnum.

Verified with a cl /Zs sweep of MRMesh, MRViewer, MRVoxels and MRSymbolMesh: failing-TU sets identical to the same sweep on master (4 known no-PCH artifacts in MRMesh, 82 in MRViewer, 0 elsewhere), and MRMesh.dll links, which exercises the four new out-of-line definitions. The include-graph pass reports no remaining user of the dropped headers and no std header lost.