Generate SummaryHandle ids as the summary moves up the layers

[agarwal-navin]

Background

This change is aimed at removing the tracking of basePath, localPath and additionalPath from SummarizerNode. These are used in case a node did not change and it's summary is a SummaryHandle. These paths are used to generate the SummaryHandle's id.

There is no need to track these three paths across summaries of this node because they don't change anymore. They make the summarizer node code complicated and hard to understand / make changes. Previously, these paths could change from one summary to another because of 2 reasons:

1. When transitioning to writing summary trees under .channels sub-tree. We have to support loading from snapshot where summaries were not written under .channels sub-tree. This PR adds a fix for that - Regenerate the first summary (i.e., don't use incremental summaries) when loading from such snapshots.
2. Differential summaries where if a node failed to summarize, we would use the previous summary + a blob where its ops would be stored.

Description

This PR is one of 2 ways we can acheive removing these paths. The second one is #19015.

Note: It does not remove basePath, localPath and additionalPath from SummarizerNode yet. It removes its usage and can be removed. I didn't remove it to make the change smaller and easier to review.

It completely removes any handle is tracking from summarizer node. A summarizer node always returns "/" as its SummaryHandle id. The parent layers prefix the rest of the path as this summary makes it way up to the container runtime. Basically, the SummaryHandle is relative to this node. It's saying that all of itts my previous summary ("/"). This becomes interesting when doing incremental summaries at sub-DDS layer which will set the SummaryHandle id relative to the DDS - something like "/subDDSTree1/blob1".

This is consistent with how the summary tree is generated where each node just returns its summary tree and doesn't know or care about its id. The parent node is the one that adds its summary tree against its id. GC also works similarly. The idea being that a node only knows about the world under it and if you cut-off the object tree at this point, this node is self-sufficient and can summarize / run GC for its sub-tree.

This fix is slightly expensive than https://github.com/microsoft/FluidFramework/pull/19015 because it requires iterating through the entire summary tree and update handles. However, this is more consistent with the rest of the system.

Sub-DDS incremental summary

Additionally, with this change, IExperimentalIncrementalSummaryContext doesn't need summaryPath to do incremental summaries at sub-dds level. The handle id for any SummaryHandle in the DDS content has to be relative to the DDS. This is the correct usage pattern anyway. DDSes should not care about what the path to it is. That is controlled by the runtime and DDS has no control over it. All it needs to say when using a SummaryHandle is - Use this path from me from the previous summary for this sub-tree summary.

AB#3740

[vladsud]

When transitioning to writing summary trees under .channels sub-tree. We have to support loading from snapshot where summaries were not written under .channels sub-tree. This PR adds a fix for that - Regenerate the first summary (i.e., don't use incremental summaries) when loading from such snapshots.

I assume we have UTs to validate this path, right?