Re-export TraitList/TraitSet/TraitDict containers (not handlers) in API?

Currently `TraitListObject`, `TraitSetObject` and `TraitDictObject` are exposed in the `api` module, but their corresponding base classes `TraitList`, `TraitSet` and `TraitDict` are NOT exposed in the `api` module.

I am not sure whether `TraitList` are safe to be used externally, because of the following circumstantial information:
(1) Traits wants to impose this rule (see #1213): only guarantee backward compatibility for things that are exported via the `api` modules, and things that are not exported via the `api` modules do not receive backward compatibility treatment. -> so it is not safe to rely on it?
(2) The `TraitList` from `trait_list_object` has a name clash with the `TraitList` from `trait_handlers`. The latter is already exported in `api`, so understandably if I want to import the `TraitList` from `trait_list_object`, I cannot import it from `api`. -> so it is actually safe to rely on, but for technically difficulties it wasn't made obvious?
(3) The `TraitList` from `trait_list_object` is visible in the public API documentation. -> so it is actually safe to rely on? (conflicting with (1))

In any case, I find myself second guessing the intention due to the name clash with `trait_handlers`. If the `TraitList` (container) and friends are not meant to be subclassed externally, it might be good to rename them or document the intention in the docstring. If the `TraitList` is meant to be used externally, make it more obvious so that developers don't have to second guess if they are doing something not meant to happen.

(Note: Motivation for this issue is that I am trying to decide whether to subclass `TraitList` or `TraitListObject` for an issue in Envisage, after exhausting all other options that don't require subclass. Judging from my own understanding of `TraitList` and `TraitListObject`, I would think it is better to subclass `TraitList`, which knows itself is meant to be subclass-ed.)