.Net: Remove Memory property from SKContext

[shawncal]

Motivation and Context

Different skills and functions require different types of memory. Some skills might just need local, high-access stores while others need remote, authenticated access. Some are powered by embedding (vectors) indexed in the cloud, while others may be generating lightweight embeddings locally, on the fly. We cannot assume that memory is "one size fits all", or that even all the skills/functions in a single Plan use the same memory provider.

Description

Instead of surfacing one single 'Memory' instance to all skills, we're peeling this back and simplifying somewhat. In this first pass, the Memory property of SKContext is removed. The updated guidance will be to instantiate Skill classes with the memory provider you'd like them to have access to. This also opens the door for the TextMemorySkill to be registered several times in the kernel (with different aliases), granting access to different memory stores.

BREAKING CHANGE: though this is not expected to have a large impact, updates will be required for anyone:

• using SKContext.Memory: will need to pass it into the function via an alternate route; likely Skill constructor injection
• or those using the new SKContext() constructor and explicity passing the optional ISemanticTextMemory: creating a new SKContext with the new constructor is not advised, as this is typically done by a call through the Kernel. The new SKContext constructor is planned to be hidden in a future release.

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 😄

[stephentoub]

Delete all the things :)

[RogerBarreto]

Food for thought.

I saw that the suggested implementation in this change for the MemorySkill was injecting the Memory when the skill was constructed not on usage/context basis.

Currently in our implementations there's no way to access our available AIServices based in the context of execution of a skill and IMHO we should think in a scenario where we should be able to get a service from within a Semantic Function depending on the context it is being executed.

i.e: Memory Skill might use different memories/text completion services when executed from different IKernels using the same ISkillCollection...

[shawncal]

Food for thought.

I saw that the suggested implementation in this change for the MemorySkill was injecting the Memory when the skill was constructed not on usage/context basis.

Currently in our implementations there's no way to access our available AIServices based in the context of execution of a skill and IMHO we should think in a scenario where we should be able to get a service from within a Semantic Function depending on the context it is being executed.

i.e: Memory Skill might use different memories/text completion services when executed from different IKernels using the same ISkillCollection...

Yeah good call. To do this currently, you would create several TextMemorySkill instances and name them with different skill names (aliases).

The single memory provider is the core problem we're (starting to) fix with this PR. This change is one of likely several (to keep it "focused").

Additional changes ahead:

• Moving memory skill into its own package, so it can evolve and grow faster than SK.Core
• Consider having a collection of memory services registerable in Kernel, instead of just one (may or may not be needed)