Re-work of the logging / debug bar panel feature, and other small changes.

[GaryJones]

Re-work of the logging / debug bar panel feature:

• Main class pulled into a separate file, leaving main plugin file lighter (could still do with some work).
• Debugging (or more strictly, logging) features abstracted from main class into its own class. The main class still uses a handy debug_log() method, but this is just a wrapper for a separate logger class. An instance of the logger class is injected via a set_logger() method in the main class. This leaves the main class as just being the plugin functionality, with optional logging. This class has no knowledge of what is done with the logs (i.e. used in debug bar panel class).
• The logger class takes it's structure from PSR-3, with the intention that another PSR-3 compatible logger class could be used in the future with minimal changes. Note that the logger class has no interaction with WP function calls etc. so this class could be developed into a more generic Blazer_Six_Logger class (that covers all log level methods used in PSR-3) for use in other projects or WP plugins. This class has no dependencies and no knowledge of how the logs were collected or what will be done with them.
• The Debug Bar panel class only deals with the logger class, and is somewhat dependent on the structure under which the logger class stores each log. It has no knowledge of how the logs were collected, or even what they apply to. This could be made into a more generic Blazer_Six_Debug_Bar_Panel class, and then extended to make it specific for this plugin (e.g. panel title, styling).

Other changes:

• Main class no longer uses a singleton pattern. It is instantiated within the main plugin file.
• wp_embed_handler() method adds an oembed="1" attribute, so that grouping of log messages can take account of whether a raw oembedable URL was used, or the direct shortcode that the URL would have converted to.
• Debug bar panel has amended styling - keeps each message as a string (as per PSR-3), groups messages by a hash of the processed shortcode attributes, includes a respresentation of the raw shortcode as group title.
• Debug bar panel hidden when there are no log messages to show.
• Fixes Check line-highlighting logic #3 for correct line highlighting, and improves it by adding trim()s, so that values like " 1, 5,9 -13" will work like "1,5,9-13".
• Similar trim()s added for line number attributes.
• Enqueuing of style sheet changed to correct hook.
• Added localization support (no .po/.mo generated yet).
• Documentation improvements.
• Addition of me as an author, due to significant code changes.
• Version bump to 1.2.0.

[bradyvercher]

Nice! I like what you've done overall and will spend some time checking out the standards you mention. I do have a couple questions just to seek clarification for my benefit and will leave a some comments in the commit.

• Not sure the version bump is necessary, since 1.1.0 hasn't been released yet.

[GaryJones]

Ah, if 1.1.0 isn't out, then no need for my version bump.

For each of the points you highlight that need a change, I'll do further commits to my branch (and therefore this PR), before you commit.

[bradyvercher]

I think those were the main things I had questions about. There may be a couple of additional formatting things I noticed on first glance, but have to read back through and can take care of them.

I think the ksort() in the shortcode hash method can be moved to the main shortcode method just after the attributes are sanitized. And maybe save the hash to a local variable in methods where it's being used quite a bit instead of repeatedly calling the method, but that's stuff I can take care of.

This isn't in the plugin repository because I mainly built it for use on our site, but I'm not opposed to renaming it and submitting with you as a contributor if you're interested.

[GaryJones]

I think those commits should take care of the queries you raised.

I'm not fussed about it going into the plugin repo - I've been thinking of pulling my existing ones out of there anyway and just having them on Github / my own repo - but if you want to push to the WP repo I have no objections about being listed as a contributor.