PR: Different project north rotations depending on linking in IFC and corresponding .ifc.rvt file

### Problem Description

This is a related issue to #522 .

When an IFC is linked, in the background it generates a correlating .ifc.rvt file. When an IFC is linked via "Link IFC", bug #522 is triggered: that is, the IFC's +Y project north correlate's with Revit's true north in versions 2022 and up.

The problem is the inconsistency between linking the IFC directly and linking the .ifc.rvt. If you link the .ifc.rvt, the opposite (desired) behaviour happens: the IFC's +Y project north correlates with Revit's project north. The problem is that sometimes users link in the IFC directly and sometimes they share the .ifc.rvt and link that artefact in instead (this saves on having 5 subcontractors having to wait an entire afternoon to load in an IFC ... instead only one person links the IFC, then they share the .ifc.rvt). So depending on which method you use you get different results.

Note that linking in the .ifc.rvt is actually the desired behaviour, firstly because it gets the project north correct, and secondly because it actually gives you options of mapping things like PBP -> PBP (in contrast, linking IFC is stuck on internal origin, see #320 ).

Now we have this strange workflow where we say step 1) link the IFC, 2) remove the link, 3) link the .ifc.rvt using PBP as the origin and only then it'll come in correctly.

### Revit Version

2023.1.x

### IFC for Revit Addon Version

24.x.x

### Windows Version

11 22H2

Start by reproducing the two workflows described in Revit 2023.1: link the IFC directly, then link the generated .ifc.rvt, and compare project-north rotation and origin-mapping behavior. Review related issues #522 and #320 for context; done means both workflows produce consistent project-north behavior while retaining the desired PBP mapping options.

Written by the indexing model from the issue text.