Automatically reload settings profile if it's redefined

[DRMacIver]

This is me following up on my note for later.

Previously if you reregistered a profile you'd need to then load it again before it came into use. This changes the logic so that's not the case.

The main motivation for this is is that if a user registers a CI profile this now ensure it will automatically be used on CI.

[Zac-HD]

I'm overall -1 on this change, because it adds yet another complication to the already complicated behavior of our settings, and it's easy enough to get the same effect by typing settings.load_profile(whatever_you_registered) (and maybe if "CI" in os.environ:).

I'd even like to warn users about profile name collisions someday, and explicitly encouraging overrides feels counterproductive for that.

[DRMacIver]

Hmm I think it actually decreases how complicated the system is by removing things it's possible to get wrong. It means that there's a coherent concept of "the current profile" which you can never be out of sync with.

I think if we didn't want profiles to be redefinable (which I'm not convinced of as a goal) we shouldn't have added a "ci" profile, and we can't add any other profiles in future.

[Zac-HD]

Right, thinking about it as ".register_profile() reloads the current profile, to ensure that stays in sync" makes sense.

With that in mind I'd move most of the new docs to the docstring of .register_profile(), describe this as a general feature illustrated by the CI profile as one example, and just include a short reference to that from the current location.

[Zac-HD]

typo?

[DRMacIver]

Yes. Also apparently unneeded given that coverage tests aren't failing!