Unify & @Stateful ItemSubtitlesViewModel

[JPKribs]

Summary

Migrates SubtitleEditorViewModel to be called ItemSubtitlesViewModel and make it @Stateful. Update all impacted views to work using the new @Stateful APIs. Finally, cleanup the subtitle search view to utilized the shared iOS & tvOS form overload since this is used in both environements. All other views are just cleaned up but otherwise still just iOS since we cannot upload or edit subtitles from tvOS only search.

On top of these core changes, I've done some more generic cleanup:

• Utilize StateAdapter where possible. On ItemSubtitlesView I couldn't figure out how to use this for a shared delete button since it seems to freak out when used in a Swipe Action so that's the only instances I left with a state isPresenting bool.
• Refreshes the item contents in the ItemSubtitlesView when FirstAppear since we need that for all the subtitles in case of change.
• Utilize EditMode insread of @State isEditing. It's my understanding that when a view owns the edit state it should use EditMode. If the view should be able to observe the editing state but NOT be able to change it, then we use isEditing. Let me know if that is incorrect!
• Some internal cleanup in the ViewModel to combine some functions since they're just adding clutter and only used in a single place.
• Moved the shared var to the ViewModel for things like language selection since that will be used for upload as well. This cleans up the need to init that per view and preserved it between upload and search.
• Moved all the upload file logic to the ViewModel. Primarily, this is because the view had a try catch in it and that meant I needed an error variable and track the ViewModel .error so getting this all in the ViewModel made that cleaner. Also builds the upload dto in the ViewModel to trim down the view itself.

Issues

Not an issue but I added:

// TODO: Option to remove `None` as an option
// - Likely just an init for Binding<String> instead of Binding<String?>

Because "" / None doesn't work for our subtitle search API. I have a catch to just return [] but it would be cleaner IMO to just be able to remove None as an option. I was thinking like, if the binding is String? we include None otherwise we don't if String.

IMO, an issue for another time but I left a TODO.

---

So, when I first did this I had a like 1.5 second wait since it seems to take Jellyfin roughly that long to show the subtitles on upload/deletion. Right now, we don't have this, instead relying on the item update to show our changes. This can result in an issue where you upload or search & set a subtitle and the list doesn't update. I'm not sure why this is the case. I believe this is more on the server that the server should have the item fully updated prior to marking the task as complete?

Some solutions I thought of (none of these are ideal):

1. Add back in the 1.5s delay to ensure time for the item to update and reflect the changes
2. Poll the item on change. On Set/Upload/Delete the BaseItemDto should always vary from the original if we poll the item and only update the item when newItem != item then we can ensure that we're capturing the change
3. Change the .onFirstAppear to .onAppear and refresh the viewModel on the view appearance. This is kind of better since this let's the user make multiple subtitle changes and we're not updating the item until it would actually matter in the view itself.
4. Leave this as is and just add a label like "Subtitles will appear when available from the server. This may take a moment."

Why can't we just make the update in the local file?
We perform deletions from the subtitles based on the index. As we know, Jellyfin subtitle indexes can surprise us. By re-getting the subtltes, we know the indexes are correct and prevent deletions of the wrong index.

[JPKribs]

I'm away from my computer but I will likely be changing this this evening to mirror how the search/denounce works from: #1945

I think the way that I did it here is incorrect and I should better reflect how it's done in item identification

[JPKribs]

I'm away from my computer but I will likely be changing this this evening to mirror how the search/denounce works from: #1945

I think the way that I did it here is incorrect and I should better reflect how it's done in item identification

Okay, I believe this is resolved now! Please let me know if that is not the case!