feat: add [MapperNoInlining] attribute and MapperAttribute.NoInlining property

[trejjam]

feat: add [MapperNoExpressionInliningAttribute] attribute and MapperAttribute.NoExpressionInlining property

Description

When a mapper referenced via [UseStaticMapper] is used from a mapper that has IQueryable projection methods, Mapperly attempts to inline or rebuild the referenced mapping methods into expression trees. For enum mappings configured with EnumMappingStrategy.ByName where the source and target enums have different underlying types, this rebuild in expression context produces false RMG037/RMG038 diagnostics — reporting all enum members as unmapped even though they match by name.

I understand the rationale behind the expression-context restrictions for the general case, and the 5.x alpha series has been catching up and tightening these rules further, which makes sense. However, in my project I was relying on [UseStaticMapper] with enum-by-name mappings in queryable projections, and the stricter inlining behavior broke that usage. We've discussed the projection + enum + inlining interaction before.

This PR adds a general opt-out mechanism for expression-tree inlining:

• [MapperNoInlining] — method-level attribute to prevent a specific mapping method from being inlined/rebuilt in expression context
• [Mapper(NoInlining = true)] — mapper-level property to prevent all methods of a mapper from being inlined when referenced via [UseStaticMapper]

Both are applied on the callee mapper (the one being referenced), not the consuming mapper.

Example

// Per-method opt-out
[Mapper(EnumMappingStrategy = EnumMappingStrategy.ByName)]
public static partial class EnumMapper
{
    [MapperNoInlining]
    public static partial TargetStatus MapToStatus(this SourceStatus source);
}

// Or per-mapper opt-out
[Mapper(EnumMappingStrategy = EnumMappingStrategy.ByName, NoExpressionInlining = true)]
public static partial class EnumMapper
{
    public static partial TargetStatus MapToStatus(this SourceStatus source);
}

When inlining is disabled, the method call is preserved as-is in the expression tree. The ORM evaluates it client-side instead of attempting to translate it to SQL.

Changes

• New MapperNoExpressionInliningAttribute marker attribute (AttributeTargets.Method)
• New NoExpressionInlining property on MapperAttribute (default: false)
• Check in InlineExpressionMappingBuilderContext.TryInlineMapping() before dispatching to inline/rebuild
• Configuration pipeline wired through MapperConfiguration and MapperConfigurationMerger
• Tests covering: bug repro, method-level attribute, mapper-level property, combined, non-projection (no effect)
• Documentation in queryable projections guide with runtime behavior comparison

Disclosure: This PR was produced with AI assistance. All code has been manually reviewed, verified, and iteratively refined by me to ensure correctness and adherence to project guidelines.

Checklist

• I did not use AI tools to generate this PR, or I have manually verified that the code is correct, optimal, and follows the project guidelines and architecture
• I understand that low-quality, AI-generated PRs will be closed immediately without further explanation
• The existing code style is followed
• The commit message follows our guidelines
• Performed a self-review of my code
• Hard-to-understand areas of my code are commented
• The documentation is updated (as applicable)
• Unit tests are added/updated
• Integration tests are added/updated (as applicable, especially if feature/bug depends on roslyn or framework version in use)

[latonz]

Mapperly usually only reads configuration through ctx.Configuration / from the mapping itself. IMO the correct way here would be passing it through the mapping. ctx.Configuration is available in the user mapping extractor.

[trejjam]

I am not sure if this is expected behavior or not.
When I was looking for a similar tests, I found MapPropertyFromSourceUseWithUnsatisfiableParametersShouldDiagnostic. Is this cascade expected, or should we prevent it?

[trejjam]

If I am not mistaken, I saw Mapperly produce an exception for such occasions. That silences the CouldNotMapMember.

[trejjam]

I hope the ctx.SymbolAccessor.HasAttribute is a sufficient solution for the Mapperly usually only reads configuration through ctx.Configuration. From what I found, it's cached, so it should not be a performance issue.

When constructing Mapper -> AnotherMapper -> Method. We need to get info about the AnotherMapper. I did not find better way than ctx.AttributeAccessor.AccessFirstOrDefault. If you want it differently, can you point me in the right way?