Replacement of IfcLogical with OPTIONAL IfcBoolean

Description of the proposal:
#36 describes a number of simplifications to the IFC "base" datatype system. Despite being marked as "decision made" with strong consensus, the base types called out for simplification remain in IFC4.3.

In particular, we call to remove `IfcLogical` and the underlying EXPRESS `Logical` type, replacing all occurrences with `OPTIONAL IfcBoolean`.

Describe how it contributes to the objectives (https://github.com/buildingSMART/NextGen-IFC/wiki/Towards-a-technology-independent-IFC):

To maintain "technology independence", the model should be rooted in concepts that can be implemented in multiple schema language. Many schema languages support booleans and most support optional properties. Fewer support a true ternary data type. Replacing all instances of a ternary Logical type with an optional boolean simplifies integration.

Is this a proposal to 'add', 'remove' of 'change' entities in the schema (pick one):
change

What do we win:
Schema simplification.

What do we lose
Explicit IfcLogical type, replaced by an OPTIONAL IfcBoolean pattern.

Schema impact:
Removable of all Logical types or their derivatives.

Instance model impact:
Replacement of Logical instance values with a Boolean or NULL ($ in STP).

Backwards compatible:
No.

Automatic migration possible:
Yes.

Additional implications:

-
Note that not all points need to be satisfied!
Backwards compatibility and file size are not concerns.

Start by reviewing proposal #36 and locating every IfcLogical and EXPRESS Logical occurrence in the IFC4.3 schema. Determine the complete schema and instance-model impact, then verify that all affected occurrences use the proposed optional-boolean pattern and that migration implications are documented.

Written by the indexing model from the issue text.