`can_be_true` and `can_be_false` should be properties

[sobolevn]

Right now they are defined as:

        self.items = items
        self.can_be_true = len(self.items) > 0
        self.can_be_false = len(self.items) == 0

But, I can see a potential inconsistency here. Since items is writable and mutable (list), someone (let's say in a plugin) can add an item to Tuple, Union, or TypedDict without updating can_be_true and can_be_false attributes.

But, @propertys are dynamically computed, so it will always produce the correct result.
It is also used not-to-often, so it should not slow down the whole program.

I will send a PR with the proposed changes.

[sobolevn]

After #11197

[joaopedro-s]

Hi,
I'm new to the mypy and was looking for open issues to do my first contribution, and when analyzing this one, both "can_be_true" and "can_be_false" are properties in types.py, probably been solved in a previous pull request, so this issue could be consider to be closed.

[hauntsaninja]

Thanks! They're properties but I think that's just for lazy init. Either way, I don't see the code Nikita is referencing on master. There's something like it in TypedDictType, where if we're worried about mutability we could type TypedDictType.items as Mapping instead of dict