Fix two sources of references to detached rows

[m-akinc]

Pull Request

🤨 Rationale

While investigating a memory leak issue reported in AzDO, we found a couple places in the Nimble table code that wasn't cleaning up observers/notifiers, causing us to hold references to disconnected row elements.

There is also a FAST bug that contributes to the leak (which is getting fixed), so the leak will still not be fixed until this PR and the FAST one are both in.

👩‍💻 Implementation

1. Rows observe columns, which results in there being a reference chain from each column to each row. When the row is detached, we must remove the column observers.
2. The keyboard navigation manager has logic for storing the row notifiers it creates, so that it can clean them up at the appropriate time. However, by a simple oversight, we were never actually adding the notifiers to the array.

🧪 Testing

Verified (in Chrome dev tools) that after these changes, detached rows are no longer referenced via the columns or keyboard navigation manager.

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[m-akinc]

@atmgrifter00 would you please buddy?

[rajsite]

@m-akinc thinking back historically on changes we have made to FAST Foundation and then having discovered:

• It fails their tests (which don't run automatically)
• It causes some other issue in full integration (like how we found the chrome crashes)

For the two PRs that are being merged into FAST archives:

microsoft/fast#6960
microsoft/fast#7023

• Do we feel confident that their tests pass and won't be an issue for releasing for the FAST maintainers?
• Have we done a full test with local tgz builds in nimble and as a full integration in an SLE app (manual and CI testing)? Given that the memory leak is blocking table adoption I want us to do our best to avoid needing additional update cycles in FAST.

[m-akinc]

@rajsite I think that has been done for the older fix, but not for the memory leak issue. The memory leak fix ought to have very limited ability to affect anything in an unexpected way, unless unbind() is called (unexpectedly?) at a time other than the node disconnecting, or if the binding observers have a bad reference, or something like that. Still, it's probably a good idea to do at least a quick sanity check, so I'll do that.