Fix matchResponseMapWithRequests to handle prompt response.

[bglgwyng]

app :: forall t m. (MonadHeadlessApp t m) => m (Event t ())
app = mdo
  ePostBuild <- getPostBuild

  rec (_, eRequest) <-
        runRequesterT
          ( do
              eX <-
                requesting (ePostBuild $> Const ())
              performEvent_ $ ffor eX (const $ liftIO $ print "Got Response!")
          )
          eResponse'
      (eRequest', eResponse') <-
        matchResponseMapWithRequests
          (\x -> (mkSome x, \case Some x -> unsafeCoerce x))
          eRequest
          eResponse
      eResponse <- pure $ ffor eRequest' $ fmap (\(Some req) -> Some (Identity 1))
  pure never

This minimal example demonstrates a request/response interaction. When a request is made, the corresponding response is generated immediately, as seen in the eResponse definition. However, the current implementation of matchResponseMapWithRequests doesn't correctly handle prompt responses, resulting in "Got Response!" not being printed from eX. This fix ensures that prompt responses are handled correctly, allowing "Got Response!" to be printed as expected.

[ryantrinkle]

Looks like a good patch, but I am slightly concerned about this being prompt. What if someone does something like this?

b <- requesting a
c <- requesting b

Will that create a cycle? It seems like it would. It would be great to add a test for this

Even if that does in fact create a cycle, we could still have something prompt here as an option

[bglgwyng]

I tried to add test for new matchResponseMapWithRequests, but after I read https://github.com/reflex-frp/reflex/blob/develop/test/RequesterT.hs#L80, I got confused about why the current matchResponseMapWithRequests has passed this test. testMatchRequestsWithResponses responses promptly also, why does the current test pass the current matchResponseMapWithRequests?

[bglgwyng]

I think we can refactor this code with ??? :: Event a -> Event b -> Event (a, Just b). Do we have something similar?