Feature request: opt-in relaxed strong emphasis parsing for suffix-attached languages

[leeyoung520]

Description

Strong emphasis is not recognized when the emphasized content ends with punctuation and the
closing ** delimiter is immediately followed by a suffix without whitespace.

For example:

**"가볍게 읽히는 책 5권"**, **"위로가 되는 에세이 책 5권"**, **"철학적으로 마음이 편해지는 책 5권"**처럼 다시 골라드릴게요.

The first two phrases are rendered as strong text because their closing delimiters are followed
by commas. The last phrase is not rendered as strong text because its closing delimiter is
immediately followed by the Korean particle 처럼.

The same delimiter-boundary pattern can occur in other suffix-attached languages:

**「本」**のように

Minimal reproduction

import 'package:flutter/material.dart';
import 'package:flutter_markdown_plus/flutter_markdown_plus.dart';

class Example extends StatelessWidget {
  const Example({super.key});

  @override
  Widget build(BuildContext context) {
    return const MarkdownBody(
      data: '**"철학적으로 마음이 편해지는 책 5권"**처럼 다시 골라드릴게요.',
    );
  }
}

Expected behavior

"철학적으로 마음이 편해지는 책 5권" is rendered as strong text, while 처럼 remains
normal text.

Actual behavior

The ** markers are rendered literally and strong emphasis is not applied.

CommonMark compatibility

I understand that the current result follows the CommonMark/GFM delimiter rules: the closing
delimiter is preceded by punctuation and followed by a non-whitespace, non-punctuation character,
so it is not considered right-flanking.

This request is therefore not to change the default CommonMark-compliant behavior.

Feature request

Would it be possible to provide an opt-in relaxed emphasis mode for applications that render
user-generated or LLM-generated Markdown in suffix-attached languages?

For example:

MarkdownBody(
  data: source,
  relaxedEmphasis: true,
)

An officially supported InlineSyntax for this use case would also be helpful if an option on the
widget is not appropriate.

The default value could remain false to preserve existing behavior and CommonMark compliance.

Difference from #129

This is different from #129. In this case, the relevant pattern is a closing strong-emphasis
delimiter that is:

• preceded by punctuation inside the emphasized content; and
• immediately followed by a suffix without whitespace.

The issue is reproducible with **"text"**suffix, rather than a delimiter merely appearing next
to a closing parenthesis.

Environment

• flutter_markdown_plus: 1.0.7
• markdown: 7.3.0
• Platforms: Android / iOS