Consolidate closing/removing approach across components

[jcfranco]

Description

This stems from #6775 (comment):

We should consolidate how we handle closed/removed items. I've noticed we have the following discrepancies:

1. naming: closable vs removable
2. approach: hiding vs removing the node

cc @driskull

Proposed Advantages

Consistency.

Which Component

All closables/removables:

component	prop name	approach
alert	closable	hidden
chip	closable	hidden
flow-item	removable	removed
list-item	closable	hidden
modal (deprecated)	closable	hidden
notice	closable	hidden
panel	closable	removed
pick-list-item (deprecated)	closable	removed
popover	closable	hidden
tip (deprecated)	closedDisabled	hidden
value-list-item (deprecated)	removable	removed

Relevant Info

No response

[driskull]

I think the only "removable" ones are flow-item and value-list-item. We can possibly ignore value-list-item as we plan on deprecating it. flow-item is pretty unique and we did have an issue to change it to not remove any child elements but we kind of scrapped that for now. We could revisit it but it would be a breaking change.

[driskull]

A lot of the nodes where we set them to hidden instead of removing them is because inside of those nodes we have a slot element and we don't want to remove the slot element conditionally in order to keep using onslotchange events.

[geospatialem]

Blocked by the efforts of #6473.

[eriklharper]

I'm just now learning about certain parent <> child component relationships where slotted children are physically removed from the DOM, and my first instinct is that this is an anti-pattern because the parent doesn't own the slotted children, the HTML author does, so shouldn't it be up to the HTML author to perform the node removal rather than the calcite component? I'm thinking of VDOM use cases too, where there is an expectation that the DOM reflects the app's internal state.

I imagine the flow of operations to be:

1. End user initiates a "close" action on an item
2. Child component triggers a "close" event
3. Parent listens for "close" event on child, possibly fires an additional event and swallows child event
4. HTML author's code responds to the close event, updating internal state where necessary
5. HTML author's rendering logic updates the DOM to reflect the new state, removing the closed node.

[driskull]

Yes, its an anti pattern. flow-item is the only one doing this and it will be fixed in 3x with a breaking change. At 3x, we can close this issue. #9390 #5072

panel doesn't remove elements so this chart should be updated.

I think we can close this issue and rely on #5072 cc @geospatialem