Make ETSConfig class documentation visible in the API docs

[mdickinson]

This PR provides an alternative to #1669. The goal is to make the ETSConfig docstrings available in the API docs, so that a search for ETSConfig in the online documentation gives useful results.

To that end, this PR:

• Renames the ETSConfig class to ETSConfigFactory
• Keeps the ETSConfig instance the same as before (previously, the created instance shadowed the class)
• Updates the main docstrings of ETSConfigFactory and ETSConfig.

There shouldn't be backwards-compatibility concerns with the rename: the ETSConfig class wasn't available before (since it was shadowed by the instance), and the trick of using type(ETSConfig) to get the class will still work.

I'm deliberately not exposing ETSConfigFactory in traits.api, since in most circumstances it shouldn't be used directly.

Screenshots: before

and after (only a portion of the docs shown):

[corranwebster]

I'm a little unsure if there are additional consequences of the re-naming of the class, but I think it's fine: anywhere that was using it was likely doing ETSConfig.__class__ which should still work.

[mdickinson]

I'm a little unsure if there are additional consequences of the re-naming of the class, but I think it's fine

Yes, I think it's mostly safe on the basis that the ETSConfig type was inaccessible by name before. So anyone trying to get hold of it is presumably using .__class__ or type(), and those will still work.

A late thought on the name, before it gets set in stone: would ETSConfigType be a better name than ETSConfigFactory. Both are kinda clunky, but I think I want clunky in this case, to discourage people from trying to use them.

[corranwebster]

A late thought on the name, before it gets set in stone: would ETSConfigType be a better name than ETSConfigFactory.

I think I prefer ETSConfigType.

[mdickinson]

I think I prefer ETSConfigType.

Renamed. Merging when CI completes.