Simplifying relative positioning with IfcPositioningElement

**Description of the proposal:**

With the change of `IfcObjectPlacement` having a `RelativePlacement` attribute, the encoding of relative placement can be simplified greatly.

Currently, one needs to account for the `IfcPositioningElement::ObjectPlacement` when calculating the correct origin and rotations of the context in which a `IfcGridPlacement` or `IfcLinearPlacement` are defined. My proposal is to require the `IfcObjectPlacement` entity as referenced by `IfcPositioningElement::ObjectPlacement` to always be the `::RelativePlacement` of every `IfcObjectPlacement` that is done within the context of said `IfcPositioningElement`.

Example:

Current way of obtaining the correct context of a `IfcGridPlacement`:

IfcGridPlacement
--> ::PlacementLocation = IfcVirtualGridIntersection
--> ::IntersectingAxes = IfcGridAxis
--> ::PartOfU/V/W (INV) = IfcGrid
--> ::ObjectPlacement = IfcObjectPlacement

Proposal:

IfcGridPlacement
--> ::RelativePlacement = IfcObjectPlacement

Similar procedure applies to `IfcLinearPlacement` as well.

A very bad sketch of the schema needed to understand the example (MS Paint FTW):

**Action** We need to document this in the `IfcPositioningElement` as well as `IfcObjectPlacement` descriptions, introducing an informal proposition: For context dependent positioning (like `IfcGridPlacement` and `IfcLinearPlacement`), the `IfcObjectPlacement::RelativePlacement` needs to be filled with the `::ObjectPlacement` of the corresponding `IfcPositioningElement`. Or something in the likes.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema: **change**

**What do we win:**
- simplified traversion of IFC structure to obtain correct relative placement
- removal of inverses "pointing" from resource layer upwards

**What do we lose:**
- backwards compatibility?

**Schema impact:**
- removing `PositioningElement` inverse of `IfcBoundedCurve`
- removing `PartOf..` inverses of `IfcGridAxis`

**Instance model impact:**
- none

**Backwards compatible:**
- Yes: from the physical file perspective. (given that `IfcObjectPlacement::RelativePlacement` change is out-of-scope of this change)
- No: for all implementers taking the inverses into account.

**Automatic migration possible:**
- Yes (given that `IfcObjectPlacement::RelativePlacement` change is out-of-scope of this change).