Add DeleteStreamsForSessionAsync to ISseEventStreamStore

[mikekistler]

Closes #1287

Adds a DeleteStreamsForSessionAsync method to ISseEventStreamStore for proactive cleanup of stored SSE event streams when a session ends, rather than relying solely on cache expiration.

Changes:

• Added DeleteStreamsForSessionAsync(string sessionId, CancellationToken) to ISseEventStreamStore
• DistributedCacheEventStreamStore: maintains a session index in the cache tracking stream IDs and last sequences per session; delete reads the index and removes all event, metadata, and index entries
• TestSseEventStreamStore and BlockingEventStreamStore: implemented for test compatibility
• Added 5 unit tests covering null args, no-op for missing sessions, full deletion, session isolation, and multi-stream sessions

[halter73]

I don't mind adding a method to ISseEventStreamStore that notifies it when a session has ended along the lines of DeleteStreamsForSessionAsync, but we'd have to be careful not to ever call it given a custom ISessionMigrationHandler. Also, we probably should rename it to something like CompleteSessionAsync to be less prescriptive, and have the DistributedCacheStreamStore implementation of it no-op. Even if we didn't have to worry about the race conditions, I think it might be less efficient to proactively query and delete cache items vs let them expire.

[halter73]

Outside of these unit tests, I don't see anything that calls DeleteStreamsForSessionAsync. It'd be easy enough to do so in StreamableHttpServerTransport.DisposeAsync, but that's going to run into problems once we add ISessionMigrationHandler from #1270. It also isn't helpful in stateless mode if/when we add support for that.

[halter73]

I don't see how we can easily prevent concurrent calls to UpdateSessionIndexAsync for concurrent streams from clobbering the SessionIndex causing streams to be lost. This might be tractable if we knew a given session could only be owned by this process by using a lock, but with ISessionMigrationHandler we have to consider we might have the same session concurrently handled by different machines.