[Feature Request] tensordict.entry_dtype(entry), tensordict.entry_device(entry)

[vmoens]

Motivation

In #168 we introduce tensordict._entry_class. Maybe it would make sense to have the same for dtype and device to avoid doing things like if tensordict.get(key).dtype is torch.float32.
These methods should be made public and documented.
We should find a proper way to do it with lazy tensordicts (especially stack). One option would be to take the first tensordict of the list and query that method on it, implicitely assuming that homogeneous tensordicts have been stacked. This is prone bug if one stacks tensordicts with varying dtypes but that's a behaviour that is not supported anyway (as usual: do we want to apply expensive checks or just tell the users to be cautious because we don't?)

cc @tcbegley

cc @matteobettini fyi since this implies lazy-stacked tds

[matteobettini]

Right now is it allowed to stack tensordicts with different shapes and different dtypes or devices?

If so, I think we should throw an error for any call to entry_dtype or entry_device on heterogenous shape stacks, behaving in the same way that tensordict.get(entry) does. (It will not matter if they actually have same device or dtype)

If not, that's already enough. We know that they have the same dtype ot device and we can jsut look at the first or smth