project, uniform, and contains for hemisphere, inf_cone, and all pyramid types + extensions

Besides implementing project, uniform, and contains for hemisphere, inf_cone, and all pyramid types, the following changes were made that may need to be discussed:

• rotate was added, which rotates vec2, dir2, and pos2 by the given angle.
• sphere<1, ScalarT, 2, TraitsT> was added, which is either a segment or two points, depending on the TraitsT.
  This allows a generic handling of D-dimensional hemispheres with a sphere<D-1, ScalarT, D> base.
• caps_of was added, which more or less returns the difference between boundary_of and boundary_no_caps_of.
  When caps_of is called for an object with the boundary_no_caps_tag, then boundary of the cap is returned, which allows a generic implementation of some project functions without considering the TraitsT variants.
• inf_of(cone) was added, which returns the infinite equivalent of the cone. It is also used in generic impementations to avoid code duplication.
  Here I have some specific questions:
  • Is there a way to unify the implementation of the TraitsT variants? The method body is the same, only the return type changes according to: cone -> inf_cone, cone_boundary -> inf_cone_boundary, cone_boundary_no_caps -> inf_cone_boundary I tried it with enable_if or auto -> decltype, but could not get it to work. The change from boundary_no_caps_tag to boundary_tag is also the reason why I had to change it from the inf_cone constructor. If it can be included there, the inf_of could be replaced by that constructor.
    Is there a way to specify this type mapping so that it can be used in template arguments? This could also be applied elsewhere.
  • Alternative idea: Return an inf_cone_boundary_no_caps object, that can be implicitly converted to a inf_cone_boundary object when needed. Like fractional_result
  • In which file should it be put? (currently it is in functions/objects/boundary.hh)
  • Should I add it for cylinder as well?
• I marked the converting constructors introduced in ea2785c9 as explicit after I got bitten by an unintended implicit conversion. I'm not sure if the conversion is used implicitly somewherre, especially where only the ScalarT is changed. This can be rolled back if needed, but IMHO at least the cases in which the TraitsT was changed should be explicit.
• I added object_traits for pyramids and removed the "TODO: traits" comment there. Not sure if there are also other traits this todo refers to.
  • While looking at detail/tg_traits.hh I saw that TG_IMPL_ADD_OBJECT_TYPES only adds a subset of all available objects. Not sure if this is obsolete or if the other object types should be added there.
• Should apex(pyramid) be added? There are currently over twenty different places that calculate it like apex = centroid(py.base) + normal(py.base) * py.height.
• The uniform(pyramid_boundary) variants could be implemented nicely with a variadic helper that computes the area of each parameter, randomly selects one and samples it. But I'm not sure if this would conflict with the existing initializer list variant, which picks a random one without weighting by area.