Document pattern matching limitations with compiler optimizations

[Copilot]

Fixes #237 by documenting the limitation that DelegateDecompiler cannot always decompile is ... or ... pattern matching due to compiler optimizations.

The Problem

When using pattern matching with the is ... or ... syntax, the C# compiler sometimes optimizes these patterns into comparison operations for performance. For example:

// Original code
x is TestEnum.Foo or TestEnum.Bar

// Gets compiled to something like
(uint)x <= 1

This optimization makes it impossible for DelegateDecompiler to distinguish between:

• A genuine comparison operation that the developer intended
• An optimized pattern match that was transformed by the compiler

As noted in the issue discussion, there's no way to determine how the comparison operator came about - whether it was from optimized is … or … pattern matching or from explicit user code.

The Solution

This PR adds clear documentation in the README.md Limitations section explaining this constraint. The documentation:

• Explains that pattern matching decompilation is not always possible due to compiler optimizations
• Provides a concrete example showing how pattern matching gets optimized to comparison operations
• Clarifies that this affects any type, not just enums
• Helps users understand why certain decompilation scenarios may not work as expected

This addresses the issue by setting proper expectations for users encountering this limitation.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>'or' pattern matching issue</issue_title>
<issue_description>With .NET 8, enum computed properties that use 'or' pattern matching returns different results that using the '||' operator.

It seems to be related with the way .NET 8 optimize the code using the 'less than' operator and the int value of the enum.
I have attached a small sample that reproduces the problem. Using the 'or' pattern matching, the query returns more entities than using the '||' operator.

EnumPatternMatching.zip

</issue_description>

<agent_instructions>Update README.md with Limitations that it is not always possible to decompile is ... or ... pattern matching due to compiler optimizations. Use issue discussion as context.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@hazzik I would not be able to untangle the results. How I suppose to distinguish between genuine `<` and `or`? @hazzik When compiler compiles `is … or …` it sometimes optimizes the IL code to produce the `<`.

What I’m saying is that for me it would not be possible to know how the < came about: was it optimized is … or … or it was used in the user code. </comment_new>

Fixes #237

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[hazzik]

@copilot simplify the language.

[Copilot]

@copilot simplify the language.

Simplified the language to be more concise and direct. Commit cc1a92a

[hazzik]

@copilot add SomeEnum definition for clarity.

[hazzik]

@copilot usually it is (uint)x <= 1u

[Copilot]

Updated the example to use (uint)x cast as it's more accurate. Commit 75f3c10