Update ContentRenderer.php

[mathetos]

Closes #17

Adds the markdown_alternate_conversion_error_fallback filter so theme and plugin authors can customize what is returned when HTML-to-Markdown conversion throws an exception.

Context

Developers currently have no way to customize the fallback when HTML-to-Markdown conversion fails (e.g. malformed or unusual HTML). This PR adds a filter that runs only when conversion throws, letting them change the fallback (e.g. logging, custom formatting, or different plain-text handling). The default remains wp_strip_all_tags() plus html_entity_decode(); the filter simply makes that behavior overrideable.

Summary

This PR can be summarized in the following changelog entry:

• Enhancement: Add markdown_alternate_conversion_error_fallback filter so developers can customize the fallback output when HTML-to-Markdown conversion throws an exception.

Relevant technical choices:

• Filter signature: apply_filters('markdown_alternate_conversion_error_fallback', $default_fallback, $content, $post, $e) — passes the default fallback, raw HTML, post object, and exception so implementations can log, inspect, or fully replace the fallback.
• Default fallback: Uses wp_strip_all_tags() and html_entity_decode() for plain-text output, matching the bug-fix behavior.
• Try/catch: Wraps the converter call in try/catch so the filter only runs when conversion fails.
• Catching \Throwable: Handles both Exception and Error to avoid uncaught PHP 7+ errors.

Test instructions

1. Add a filter for markdown_alternate_conversion_error_fallback that returns custom text (e.g. "Conversion failed").
2. Use a post whose HTML causes the converter to throw (or temporarily force an exception in the converter).
3. Visit the post’s .md URL.
4. Expected: The custom fallback text from your filter is shown instead of the default plain-text output.
5. With the filter removed, verify that normal posts still convert to markdown.
6. Verify that the default fallback still works when the filter is present but returns the first argument unchanged.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies — Test with at least one post and one page.
• Changes should be tested on different editors (Block/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Documentation

• I have written documentation for this change.

Quality assurance

• I have tested this code to the best of my abilities.
• I have added unit tests to verify the code works as intended.
• I have checked that the base branch is correctly set.

Closes #17