Brief summary of issue / Description of requested feature:

It is currently harder than it needs to be when debugging issues when a profile is starting up because it is not possible to open the Central Debug Console before a profile is loaded as the only way to activate it at the moment is via a push button on a profile's editor and that is not accessible until a profile is already loaded.

Steps to reproduce the issue / Reasons for adding feature:

1. Whilst there is currently a work around - by opening a second profile and using it's editor's button to open the CDC before opening the profile of interest, this is not as simple as it could be for a novice user.
2. The above solution does complicate the information that the end-user will have to comprehend from the CDC as there may be output from the second profile intermingled with the one of interest - whilst PR Enhance: show profile indication in central debug console output #4781 is designed to help with that by helping to disambiguate where each piece of information in the debug console comes from it would be simpler if there was no need to open another profile just to be able to get to the button needed.

Error output / Expected result of feature

Some of these:

1. A checkable menu bar item (probably under the "Toolbox" submenu) should be available which can be clicked to toggle the display of the CDC.
2. A checkable toolbar button to do the same as 1. - however given space constraints this should, I feel, be deferred until we provide a means for the end-user to arrange and select which buttons are on the main tool bar.
3. A command line option - say -d/--debug will cause the CDC to be shown as soon as possible after the Mudlet application is started.
4. The CDC display state (shown/hidden) is stored within the main application settings and reapplied when Mudlet is restarted - so that if a session ended with it showing, it is reshown the next time Mudlet is run. If 3 is also implemented the provision of that command line argument/option should override a hidden state setting from this.

Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:

Currently - as a result of - the (void) mudlet::attachDebugArea(const QString&) method, introduced in #2950 - there has been a link made I believe to the font choices of the associated profile.

I am of the opinion that this needs to be undone for this issue to be fully addressed - as there need not be a Host instance around when the CDC is created.

I have, in the past, mooted having the ability to handle <SGR>10m to <SGR>19m (Primary, plus up to nine alternate, fonts) to Mudlet - this would entail adding some means of font storage to the TChar class - but then it could mean that text in the CDC could use the relevant fonts selected in each profile for data coming from that profile and a neutral one for non-profile texts - so would not require a Host to copy font settings from.