Add support for unique aspects without requiring ECInstanceId

[jackson-at-bentley]

This PR brings the API of ElementAspectNode closer to the other nodes that create elements with navigation properties.

Keep in mind that ElementAspectNode only supports the creation of unique aspects. Tracking the provenance of bis:ElementMultiAspect is trickier and not really doable without changes to the iTwin APIs. fir doesn't make any attempt to do so and just reinserts all aspects attached to an element.

As originally written, the connector author has to intervene in the DMO and specify the ECInstanceId of the element to attach the unique aspect to. Now there's an optional elementAttr in ElementAspectDMO. It's optional to allow compatibility with the old API, which means if you forget to specify both elementAttr and the element property of your node PCF will throw at runtime. If we can confirm anyone isn't using the old API (very likely) I'd like to drop it.

I've also made changes to the synchronization of aspects to properly track the provenance of an aspect if it attaches itself to a different element. This solution is a hack, but I have a PR open to discuss alternatives.

[jchick-bentley]

@akshay-madhukar @admccarthy1 Can you please have a look at these diffs esp. *.ts changes for unique element aspect enhancements? Thx.

[jackson-at-bentley]

Yeah, sorry. In the future I'm going to move documentation changes to their own PR even if they're documenting this PR's changes. Too noisy otherwise.

Here's a link to what changed.

Rebased onto main and removed docs.

[jchick-bentley]

@akshay-madhukar Hi Akshay, could you please have a look at this PR? We're hoping to get this merge before Jackson's internship is complete.

[jackson-at-bentley]

I've reverted the changes I made to Zach's syncProvenance. Updating an external source aspect from the perspective of the one in the source data (the one we construct from the IRInstance) means relying on unspecified behavior from the backend if the element property changes. The way I've modified syncElementUniqueAspect means we may try to update an external source aspect using a different element in that first call to syncProvenance.

Ideally we'd break up syncProvenance into two functions: one that does the external source aspect comparision, maybe

function compareExternalSourceAspect(arg: SyncArg): ItemState { ... }

and syncProvenance which actually writes the aspect if it's changed. Anywho, less code to review now.