Instance call support: @ separator, void-returns-Any, hybrid field type system, and class method emission

[joehendrix]

Summary

Three interrelated changes to the Python→Laurel→Core pipeline that enable correct handling of instance methods, void procedures, and user-defined class fields:

1. Unambiguous @ separator for instance methods — Storage@put_item instead of Storage_put_item, eliminating collisions with underscored names
2. Void procedures return Any — all PySpec procedures now have exactly one output (void returns Any via from_none), removing special-case void handling at call sites
3. Hybrid two-kind field type system — builtin types (int, str, bool, float) become Any on Composite fields; class types (PySpec services, user classes) stay Composite, matching parameter semantics at call boundaries
4. User-defined class method emission — class method definitions (Counter@__init__, Counter@increment) are now included in the Laurel program as static procedures

PythonToLaurel changes

• @ separator applied across PythonToLaurel, PythonToCore, PySpecPipeline, and Specs/ToLaurel
• New translateFieldType helper maps builtins→Any, composites→Composite for field declarations
• self parameter typed as Composite (not Any) in __init__ and user methods
• Removed wrapFieldInAny for self.field reads in method bodies — builtin fields are already Any-typed
• unsupportedConstruct error thrown when Composite→Any coercion is attempted (e.g., returning a Storage field as str)

LaurelToCoreTranslator changes

• Statement-position calls now synthesize throwaway $unused_N variables to match output count, fixing Core arity checks for void-returns-Any procedures
• Single-target Assign with StaticCall also synthesizes extra LHS variables for multi-output procedures

Testing

• New dispatch tests for void assign/init, non-void discard, instance call result, user class construct, class field assign, and class method return
• Two negative tests for Composite↔Any kind mismatches: test_class_composite_as_any (Composite field returned as Any) and test_class_any_as_composite (Any value assigned to Composite field). The latter requires explicit pyspec paths since IdentifyOverloads resolves modules from complete programs with main, not isolated class snippets.
• 7 regenerated expected_laurel files reflecting the new field type system

Known limitations

• Composite→Any coercion (e.g., returning a Storage field as str) is explicitly rejected with a user-facing error. Coercion functions are being developed separately.
• Procedure names used as type annotations (e.g., Storage_put_item as a type) silently fall through to Any instead of producing an error or warning.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[joscoh]

Not necessarily blocking, but the ... ++ "@" pattern appears 9 times throughout the code. If we ever want to change the naming convention, it would be better to have this in a separate function.