Allow updating things/items/sitemaps by recreating them

[jimtng]

Also includes some minor bug fixes

• notify_listeners_about_updated_element(_old_element, element) needed two parameters
• do an identity lookup for elementToProvider. Note, I tried .to_h.compare_by_identity, but it didn't do as expected.
• It was possible to "add" new items/things/sitemaps that already existed when they were created by other providers.

Previously a newly created item will replace the existing one accidentally when calling NewItem.label = "label" during the building process. #label= calls provider&.update and because provider look up is based on item's uid (item name) it found a provider, and proceeded to update/replace the existing item with the new item. This happens even though the newly created item hadn't been officially added to the provider, and in fact the subsequent call to provider.add will fail because it already had an element with the same uid, but the new element is now the active one, despite the failure to add.

Random notes as I come to think of them about the implementation within this PR:

• When updating an item, the old metadata doesn't get deleted. It is now deleted.

[jimtng]

The way it handles metadata now is probably not right. It doesn't wipe out the metadata when updating an item.

• Say you originally created an item with ga: Light, alexa: Light.
• Then you recreated it with just alexa: Light.
  You would expect that it will no longer have ga: Light, wouldn't you? Right now the ga: Light stays there.

[jimtng]

The way it handles metadata now is probably not right. It doesn't wipe out the metadata when updating an item.

• Say you originally created an item with ga: Light, alexa: Light.
• Then you recreated it with just alexa: Light.
  You would expect that it will no longer have ga: Light, wouldn't you? Right now the ga: Light stays there.

Updated to remove managed metadata that isn't specified in the new config

[ccutrer]

thoughts on instead of a update: true kwarg, to build, have a separate method rebuild that implies update: true?

alternately, would it make sense to have update default to true? given how it's currently implemented, it will already make sure you're not trying to replace an item from another provider, which is my biggest worry about not checking if an item already exists.

[jimtng]

Please don't merge it yet - still need to change the default to true, or refactor into separate methods

[jimtng]

thoughts on instead of a update: true kwarg, to build, have a separate method rebuild that implies update: true?

I think this makes it a bit ambiguous because you can use rebuild to create brand new elements, not just to 'rebuild', because normally you probably start out without any existing items anyway, so do you first call build, then if that failed, rebuild?

alternately, would it make sense to have update default to true? given how it's currently implemented, it will already make sure you're not trying to replace an item from another provider, which is my biggest worry about not checking if an item already exists.

I'd go with this option, which is to set the default to true. I am wondering though, would it even be necessary to offer the option of update: false at all? Should we simply just let it update whenever possible and only fail on FrozenError?