merge with stable

color: rename '_styles' to '_defaultstyles' for clarity This should make it clear the dict is only used for new config. Extensions should not modify it directly anyway since we have 'extraloader' logic for loading '_styles' too.

color: move 'styles' definition on the 'ui' object Same logic as for '_terminfoparams'. The content depends on the config so it should be specific to each 'ui instance.

color: pass 'ui' to 'win32print' Same logic as before,'win32print' relies on some data we will move on the 'ui' object soon, we update the API beforehand for clarity.

color: move the dict with terminfo parameters on the ui object This dictionnary is affected by the content of the config, so we should have one for each ui config. We rename the global dict to '_baseterminfoparams' to make the situation clearer.

color: add ui to effect rendering We'll carry more and more color specific data on the ui object. This will help isolating different color configuration from each other. For example repository config might configure special style that should not affect other ui object. The first step is to make sure the ui object is available were we will needs it.

color: initialize color for the localrepo ui The 'ui' object dedicated to a 'localrepo' is independent from the one available in dispatch (and 'uisetup'). In addition, it is created from the 'baseui' (apparently for good reason). As a result, we need to run the color setup on it after the local repository config is read. This was overlooked when the rest of the initialization changed but did not had impact yet because all setup is still global. We fix it before it is too late.

color: add a 'ui.color' option to control color behavior This new option control whether or not color will be used. It mirror the behavior of '--color'. I usually avoid adding new option to '[ui]' as the section is already filled with many option. However, I feel like 'color' is central enough to deserves a spot in this '[ui]' section. For now the option is not documented so it is still marked as experimental. Once it get documented and official, we should be able to deprecate the color extensions. There is more cleanup to do before that documentation is written, but we need this option early to made them. Having that option will allow for more cleanup of the initialisation process and proper separation between color configuration.