Assess anchoring requirements for returned values inside elided types

[arik-so]

When calling a method that requires passing a pointer to the instance, one usually assumes that the response value needs the caller's memory to outlast it.

However, if the returned object owns its own memory, that may not be necessary. Again however, if the returned object is an elided type, like a tuple or a Vec or a primitive wrapper, memory ownership check needs to be recursive. Example: ChannelManager:listChannels, which returns a Vec_ChannelDetailsZ, but the ChannelDetails are likely all owned, so the Vec may be freed.

Proposed solution: add an optional parentalAnchor parameter to getValue(), where, it checks if any of its objects don't own their memory, and then anchors the parent in them.

[arik-so]

Alternatively, check if all the contained types have an is_owned field, and if they do, simply don't do the anchoring after all.

[arik-so]

However, just checking whether they have one is not enough, because if any of the contained object has is_owned set to false, it means they're reliant on the would-be-anchor's memory, meaning that we have to recursively pass in the anchor for objects that aren't owned to store it.

[arik-so]

Perhaps call that parameter dynamicRecursiveAnchor in the getValue() method

[arik-so]

Another interesting example: PeerManager::getPeerNodeIds(). There, the function takes an instance pointer, and the returned type is a Vector of values without an ownership field. However, they are a primitive wrapper.

[arik-so]

Currently implemented approach is overriding the dangle set by an anchor (normally, using an anchor immediately dangles the object), by calling .dangle(false) immediately after.

[arik-so]

Tightly related to #24.