My plan for now is to have a feature flag in the codebase for our new talk page feature, so that we can continue to merge new work into main but still have bug fix releases before the feature goes out. We can explore moving the flag to a remote config file later if we decide it's needed.

We have a Staging version of the app that we used to deploy nightly along with our main build. Let's restore this and have it configured to show the new talk pages.

1. Undo the work done in this PR to get staging to deploy nightly again.
2. Set up a feature flag property that is true using the staging environment macro (could be something like this):

struct FeatureFlags {
    static var needsNewTalkPage: Bool {
        #if WMF_STAGING
            return true
        #else
            return false
        #endif
    }
}

3. Create a new blank view controller subclass that will eventually be the home of our new talk page.
4. Find all branches where talk pages are pushed on (you could look for wherever TalkPageContainerViewController is instantiated), check the feature flag and push your new empty view controller if it's true, otherwise push the TalkPageContainerViewController as before.

To test this: Running the Staging scheme (black icon) in Xcode should show your blank view controller, running the main Wikipedia scheme (white icon) should show the old talk page as before. Every night both the black icon build and white icon build will be pushed, and QA can test against both.

Notes for QA

1. Confirm our main Wikipedia TestFlight app continues to show our current user talk page in the right places, as well as the mobile web article talk page.
2. Confirm our new nightly Staging Wikipedia (black icon) TestFlight app shows our new (in-progress) native user talk page and article talk page work.