.Net: Moved IChatHistoryReducer from Agents to SK packages

[dmytrostruk]

Motivation and Context

Resolves: #10203

This PR:

• Moves IChatHistoryReducer from Agents.Core to Microsoft.SemanticKernel.Abstractions package.
• Moves implementations ChatHistorySummarizationReducer and ChatHistoryTruncationReducer from Agents.Core to Microsoft.SemanticKernel.Core package.

The functionality is marked as experimental.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[westey-m]

I see we copied the one from concepts and not the one from agents. I.e. the one missing the equality methods. Do we not need the equality methods after all? I'm assuming that it would be odd to create and use two reducers with the same configuration anyway, so maybe the methods aren't required. Just double checking.

[dmytrostruk]

I think there are two points:

1. It looks like the equality methods are used within the Agents scenario, but if reducer abstraction is moved to SK Abstractions, I'm not sure if equality methods are required there. If somebody wants to implement a custom reducer and use it on ChatHistory in a scenario where equality doesn't mean anything, the developers should be able to do that without defining the equality methods.
2. Even in Agents scenario, I'm not sure if Equals/GetHashCode methods should be a part of IChatHistoryReducer interface, since it's already available in System.Object and can be overridden in actual implementation. By defining it within the interface we just force the implementations to have these methods, but for such purposes maybe interface like IEquatable<T> would be a better option.

But in all cases, the first point is the main reason I decided to avoid equality methods in that interface, while the implementations ChatHistorySummarizationReducer and ChatHistoryTruncationReducer still have it, so it shouldn't impact already existing logic. If somebody wants their reducer to be used within the Agents scenario where it matters, it's possible to override them in implementations without any issues. Maybe we can specify this in the Agents documentation.

[westey-m]

Both the extension methods here can operate on ChatHistory since ChatHistory inherits from IReadOnlyList<ChatMessageContent>. Does this mean that in order to do a non mutating reduction, you have to do some casting first, like ((IReadOnlyList<ChatMessageContent>)myHistory).ReduceAsync(myReducer, ct)?
If so, would it make sense to be more explicit in the naming, so that it's easier to invoke one or the other on aChatHistory object.

[westey-m]

Also, would it make sense to support all 3 possible scenarios:

1. Mutating ChatHistory
2. Creating new ChatHistory with changes
3. Create new IReadOnlyList<ChatMessageContent> with changes

[dmytrostruk]

I agree, accessing non-mutating reduction with casting only is not a great user experience. I renamed mutating reduction method to ReduceInPlaceAsync while the methods that returns a new instance are called ReduceAsync. I'm happy to chat more about naming if needed.

[RogerBarreto]

Suggest moving the ChatHistoryReducer to its own file keeping it within MultiProviders prefix can be difficult to find, I would rather split our different ChatHistoryReducers_***Type of reducer** file.

Suggested change

	IChatCompletionService chatService = openAiChatService.UsingChatHistoryReducer(new ChatHistoryTruncationReducer(truncatedSize));
	IChatCompletionService chatService = openAiChatService.UsingChatHistoryReducer(new ChatHistoryTruncationReducer(truncatedSize));

[dmytrostruk]

I agree, but on the other hand, having these reducers in one file allows to run and compare them more easily. Since this file contains just 5 methods and around 200 lines of code, I don't have a strong preference about its structure at the moment. Maybe we can keep it as it is and split it later if it grows in the future.