## Describe your changes

This PR adds a new functionality to the `st.selectbox` and
`st.multiselect` commands, which will allow to add new options
dynamically when the `accept_new_options` argument is passed as `True`.

These PRs were merged in context of this work:
#10865,
#10891

Underlying, we change an index-based option selection with a value-based
option selection. Previously, the frontend and backend used the indices
of the selected options, since the frontend and backend had the same set
of options available. Now, the frontend can have a new option being
added dynamically. This option is not available on the backend, so we
cannot use an index. We made the decision to switch the communication to
always use strings to keep it simple.
For that, following changes are made:
- the selected values are sent via `setStringValue` and
`setStringArrayValue` from the Frontend now
- the protos for Selectbox and Multiselect are updated:
- a new `accept_new_options` field to tell the frontend whether adding
an option dynamically should be enabled
- a new `raw_value` field that replaces the old `value` field. The
`value` field was of type `int32` / `int32[]`, respectively, and is now
of type `string` / `string[]`.
- the `value` field is marked as deprecated, but otherwise left in place
so that the code is backwards-compatible.
- the `st.selectbox` and `st.multiselect` have new overloaded versions
with return types `T | str` and `list[T | str]`, respectively. This
accounts for the fact that not only the generic type `T` based on the
passed options can be returned but also strings corresponding to
dynamically created options that are of type string.

The string-based message is ~6times bigger, but note that the
measurement is in bytes. So compared to the overall communication
pattern of Streamlit with reruns and messages based on every
interaction, this number should be neglectible.

The commands `st.selectbox` and `st.multiselect` continue to return the
generic type `T` for known options. However, if `accept_new_options` is
`True`, the returned value can also contain string(s) for dynamically
added options.
Additionally, the coercion of enums corresponding to the passed
`options` should not be relied on when options are added dynamically. So
far, the `maybe_coerce_enum` function returns early when not all items
in the passed list are of type enum. A dynamically added option is of
type `str`. So, the function will always return early when a dynamically
added option of type `str` is part of the list. We will see whether the
coercion of such mixed types will be requested & voted for in the
future.

## GitHub Issue Link (if applicable)

- Closes #5348
- Closes #5744

## Testing Plan

- Explanation of why no additional tests are needed
- Unit Tests (JS and/or Python)
  - Add unit tests for Serde classes
- Add unit tests to ensure that the `accept_new_options` proto field is
present
  - Update existing JS tests
- Add unit test to ensure correct value returned from
`getCurrStateFromProto`
- E2E Tests
  - Add new e2e tests to test adding a new option dynamically
  - Add new e2e test for ensuring preset session state value is used
- Any manual testing needed?

---

**Contribution License Agreement**

By submitting this pull request you agree that all contributions to this
project are made under the Apache 2.0 license.