fix: Nullable return types

[hemanta212]

Problem

When a schema field has required: false (the default), the generated Go struct uses non-pointer types. This causes issues when the DSL specifies null as an expected value:

test "non-existent user returns null" {
    $userId: 999
    u.name: null   // expects null from database
}

Generated struct:

type getUserResult struct {
    Name string  // non-pointer - cant be nil
}

Generated mock tries to return nil for a string field - compile error.

Solution

Pass Required metadata through ReturnInfo from the analyzer layer, letting codegen (signature.go) decide pointer wrapping. Type inference stays clean (returns string), while Required bool travels separately for codegen to use with proper type inspection via isNilableType().

Changes

• dialect.go: Add Required bool field to ReturnInfo
• dialects/cypher/type_inference.go: Add FieldInfo struct and inferFieldInfo() to extract Required from property access
• dialects/cypher/analyzer.go: Set ret.Required in extractProjectionItem()
• language/go/signature.go: Use ret.Required + isNilableType() helper to wrap nullable primitives in pointers
• language/go/mock.go: Emit ptr[T any] helper, wrap non-nil pointer values with ptr()
• Tests for Required propagation, nullable return inference, and pointer mock generation

[rlch]

What is the inference logic for required? Simply whether the field has a pointer? Let's say a field has **string, does that become *string in the result struct or are types propagated exactly? Needs a bit more elaboration

[hemanta212]

• I infer types based on whether the required field in the schema is populated, regardless of what type is set to (I don’t infer from type).

• If required is false, I ensure the field is nilable. If the type is already a pointer, slice, or map (which are nilable in Go), I don’t wrap it in a pointer.

• This information is passed cleanly through the stack; the language/Go layer sees the type and required flag and performs the inference at code generation time.

[rlch]

Remove fallback and ensure tests pass after. Otherwise LGTM

Also can you submit another PR for CI on PRs?