Treat CC2340 bidirectionality as a pin capability

[AnasSarkiz]

CC2340 datasheet enrichment marks GPIO-capable pins with isBidirectional: true. The converter treated that capability as a selected GPIO function and rejected it alongside explicit input/output choices. It also incorrectly treated unconfigured SWD and connected LF crystal pins as GPIO conflicts.

Before, this valid board declaration failed:

pinAttributes={{
  pin4: { isGpio: true, isBidirectional: true, isOutput: true },
  pin5: { isGpio: true, isBidirectional: true, isInput: true },
}}

After, the same declaration exports GPIO Output on physical pin 4 and Input on physical pin 5. Capability-only SWD pins retain SDK ownership, and the existing crystal connectivity check still selects the LF oscillator. A connected ordinary GPIO without a direction still errors with its component name, physical pin and label:

- U1 pin 5 (DIO12): GPIO direction is missing

Pin diagnostics contain one line per pin, without an additional component header or instructions. I2C selection errors remain separate. The converter and CLI error tests use inline snapshots.

Validation:

• 219 tests pass, including eight snapshots; typecheck and formatting pass.
• Official SysConfig 1.28.1 with SimpleLink F3 SDK passes GPIO/I2C native validation, LF crystal round-trip C/header parity, and physical pin-change checks.
• Existing configured pedometer output remains identical when published bidirectional flags are added.

This changes converter interpretation only. No new props, board preset, inferred GPIO direction, metadata edits, or sysconfigts changes. Separate from the merged diagnostics PR #9.