Collections and common types in BVH package are named in non-conformant manner

In OCCT we have convention that name of the global class should start from name of the package where it is defined, separated and the class, separated by underscore, and normally the class is defined in the file with same name (see http://dev.opencascade.org/doc/overview/html/occt_dev_guides__coding_rules.html#occt_coding_rules_2_2).

Functionality implemented within BVH package violates this convention multiple times for collection classes and base structures. Their definition is distributed between several files like BVH_Box.lxx, BVH_Properties.lxx, BVH_Types.hxx within BVHTools namespace. Custom types are defined in structures and have public availablity (e.g. BVH_Transform::BVH_MatNt, BVHTools::MatrixOp::BVH_Mat4t). At the same time these structures itself are named in non-conformant manner (e.g. BVHTools::MatrixOp (BVH_Properties.lxx), BVHTools::CenterAxis (BVH_Box.lxx)). Definition of several types within a single header file also takes place (e.g. BVH_Transform in BVH_Properties.hxx).

File BVH_Types.hxx does not contain neither namespace nor class corresponded to the name of this header file. It defines namespace BVHTools as well as several custom types such as BVH_Vec2i, BVH_Vec3i, BVH_Vec4i, etc. Note that BVH_Vec4i is widely used in OpenGL package.

The conformance to naming conventions is crucial in many situations, e.g. automatic tools working with the code, SWIG wrapper etc. Like this, it is quite important to put BVH package in order to fit the coding rules.