Name the missing key and suggest safe access in collection key-not-found errors

[jhonabreul]

Description

Key-not-found errors from symbol-keyed collections did not always name the missing key or say how to avoid the crash. Non-string keys (e.g. a Symbol) rendered blank, and wrong-bar-type access got an unhelpful Python suggestion:

'QuoteBar' object has no attribute 'volume' Did you mean: 'value'?

The changes:

• Slice/DataDictionary indexer errors now share a single template: it names the key, renders friendly generic type names, and suggests the safe-access idiom per language (data.get(symbol) / if symbol in data: for Python, TryGetValue/ContainsKey for C#).
• Securities/Portfolio missing-symbol errors append the same suggestion.
• KeyErrorPythonExceptionInterpreter reads the key from the exception value instead of parsing the message, so object keys are named instead of rendering blank.
• New AttributeErrorPythonExceptionInterpreter: QuoteBar.volume points at data.bars.get(symbol), and TradeBar bid/ask access points at data.quote_bars.get(symbol). Other AttributeErrors are untouched.

Audited, no change needed: .get(symbol) and in already work across all these collections.

Related Issue

N/A

Motivation and Context

These are among the most frequent runtime crashes in Python algorithms. When the message names the key and the guard idiom, the failure is fixable in one shot.

Requires Documentation Change

No.

How Has This Been Tested?

• KeyErrorPythonExceptionInterpreterTests: new tests for string keys and object keys (reproduces the blank-key rendering with a Symbol-keyed dict).
• New AttributeErrorPythonExceptionInterpreterTests: asserts both hints and that unrelated AttributeErrors are left alone.
• SliceTests / SecurityManagerTests: assert the C# and Python message variants.
• Affected suites green: Tests.Common.Exceptions, SliceTests, SecurityManagerTests, ExtendedDictionaryTests, OrderTicketTests, SecurityPortfolioManagerTests (333 passed, 0 failed).
• End-to-end via Launcher with scratch Python algorithms: verified each message in the runtime error output.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>