This also changes some behavior:

1. When unsafe_allow_html=False AND _repr_html_() did not contain HTML tags
we used to send its output to st.markdown(). This behavior is now removed.
Instead, the output is handled like a normal object (that is, with st.help).

2. Removes _repr_html_ from *Connection objects. This didn't really buy us
anything, and was just weird. Also, this was the reason for adding behavior #1
in the first place.

…ions

Addresses three suggestions from PR #12807 review:

1. Simplify test cases (suggestion #2)
   - Reduced from 9 parameterized tests to 3 focused tests
   - Removed fragment and expander contexts (regression only in containers)
   - Eliminated parameterization that made test app hard to read
   - Simple, clear structure with named containers

2. Add deterministic width assertions (suggestion #3)
   - stretch: Container width=600, expect ~580-600px (allows padding)
   - content: Figure 6.4in @ 100 DPI = 640px, expect ~620-640px
   - pixel: Explicit width=500, expect ~480-500px
   - More stable than arbitrary >200px threshold

3. Clean up unnecessary comments (suggestion #4)
   - Removed comments that just describe next line
   - Kept meaningful comments explaining test logic and expectations
   - Improved readability

Test structure:
- 3 regression tests in containers only
- Specific figure size (6.4in x 4.8in at 100 DPI)
- Known container width for stretch test
- Deterministic assertions with reasonable margins

Note: Suggestion #1 (use_container_width check) addressed with explanation
in PR comment - current logic is correct for the new widthConfig system.

Addressed suggestion #1 feedback:

The suggestion to check use_container_width field revealed a TypeScript
error - ImageList proto doesn't have useContainerWidth field (unlike
chart elements). ImageList only has deprecated 'width' field (WidthBehavior enum).

Current logic is correct:
- When widthConfig is not set → default to stretch behavior (width: 100%)
- When widthConfig.useStretch → use stretch behavior (width: 100%)
- When widthConfig has other values → use auto width

The legacy 'width' field (WidthBehavior enum) is handled by ImageList
component itself, not by the container wrapper. The container just provides
the outer width context.

Updated comment to clarify this and explain the default legacy behavior.

…ions

Addresses three suggestions from PR #12807 review:

1. Simplify test cases (suggestion #2)
   - Reduced from 9 parameterized tests to 3 focused tests
   - Removed fragment and expander contexts (regression only in containers)
   - Eliminated parameterization that made test app hard to read
   - Simple, clear structure with named containers

2. Add deterministic width assertions (suggestion #3)
   - stretch: Container width=600, expect ~580-600px (allows padding)
   - content: Figure 6.4in @ 100 DPI = 640px, expect ~620-640px
   - pixel: Explicit width=500, expect ~480-500px
   - More stable than arbitrary >200px threshold

3. Clean up unnecessary comments (suggestion #4)
   - Removed comments that just describe next line
   - Kept meaningful comments explaining test logic and expectations
   - Improved readability

Test structure:
- 3 regression tests in containers only
- Specific figure size (6.4in x 4.8in at 100 DPI)
- Known container width for stretch test
- Deterministic assertions with reasonable margins

Note: Suggestion #1 (use_container_width check) addressed with explanation
in PR comment - current logic is correct for the new widthConfig system.

Addressed suggestion #1 feedback:

The suggestion to check use_container_width field revealed a TypeScript
error - ImageList proto doesn't have useContainerWidth field (unlike
chart elements). ImageList only has deprecated 'width' field (WidthBehavior enum).

Current logic is correct:
- When widthConfig is not set → default to stretch behavior (width: 100%)
- When widthConfig.useStretch → use stretch behavior (width: 100%)
- When widthConfig has other values → use auto width

The legacy 'width' field (WidthBehavior enum) is handled by ImageList
component itself, not by the container wrapper. The container just provides
the outer width context.

Updated comment to clarify this and explain the default legacy behavior.