LayoutPartialTree low level api is restrictive

## What problem does this solve or what need does it fill?

It would be nice if there was a less restrictive low-level api, within my UIs node structure my nodes are not owned but are subject to interior mutability (my trees own something akin to Rc>>), hence unless I'm missing something (which I very well may be) its impossible for me to return the references (`&Style`, `&mut Cache`) as required by `LayoutPartialTree` as it breaks rust ownership guarantees. For reference here is the current trait:

```
pub trait LayoutPartialTree: TraversePartialTree {
fn get_style(&self, node_id: NodeId) -> &Style;
fn set_unrounded_layout(&mut self, node_id: NodeId, layout: &Layout);
fn get_cache_mut(&mut self, node_id: NodeId) -> &mut Cache;
fn compute_child_layout(&mut self, node_id: NodeId, inputs: LayoutInput) -> LayoutOutput;
}
```

## What solution would you like?

I'm not 100% sure on what the ideal solution really would be. In my exact scenario a API which returned an owned `Style` (this would be a performance cost) and `Rc>` would work, however returning the `Rc>` really doesn't seem ideal to me either as this doesn't leave room for alternative mutability patterns.

MAYBE creating a Cache Trait would actually be the more versatile solution. Something like:

```
pub trait LayoutPartialTree: TraversePartialTree + CacheForNode {
fn get_style(&self, node_id: NodeId) -> Style;
fn set_unrounded_layout(&mut self, node_id: NodeId, layout: &Layout);
fn compute_child_layout(&mut self, node_id: NodeId, inputs: LayoutInput) -> LayoutOutput;
}

pub trait CacheForNode {
fn get(&self, node_id, ...) -> Option;
fn store(&mut self, node_id, ...)
fn clear(&mut self, node_id)
fn is_empty(&self, node_id)
}
```

Ideally it would be cool to have a solution which doesn't introduce any significant performance cost (`&Style` -> `Style` might, I'm not sure); and also isn't just a second low level api for maintainability purposes. Curious if anyone else has other thoughts, maybe folks like I just need to use my workaround (below), however I bet there is a good solution

## What alternative(s) have you considered?

Right now, I figured I can just use the high-level api as a workaround and rebuild the tree for each time a recomputation is required. It's just not the nicest solution but it will work.

Start by reading the LayoutPartialTree and TraversePartialTree traits shown in the issue, then inspect the high-level API workaround and how it rebuilds the tree. Compare ownership and interior-mutability constraints for the proposed alternatives; done requires an agreed low-level API that supports these node structures without an unspecified significant performance cost.

Written by the indexing model from the issue text.