Add Infiniti G25 and the VQ25HR engine

[mmsaki]

Adds the Infiniti G25 and its engine, the VQ25HR. Neither was in the tree — Infiniti already has EX, FX30d, Q30, Q50, Q50L, Q70 and QX30, and the G25 is the V36-platform 2.5 V6 sold 2011-2012.

Both entries come from probing a 2011 G25 over OBD-II and CAN with a WiCAN adapter, so the evidence line names the work rather than a tuning-tool vehicle list. Happy to change that if you'd rather evidence always be a URL.

A question, since I have more of this car than the schema takes

What I have that doesn't fit anywhere yet:

• Module addresses — which modules answer, at which 11-bit CAN addresses, and where the replies come back. On this platform 745 answers at 765 and 70E at 70F, and 743/745 are BCM/meter on older cars but swap on the 2018+ Leaf, which is the sort of thing that costs an afternoon to discover twice.
• Identity responses — Nissan answers 0x21 0x83 with an identification block that breaks into named fields.
• A protocol quirk — Renault-Nissan platforms need a KWP DTC read when 0x19 returns nothing, otherwise a module holding codes reads as clean.

Would you be open to carrying addresses on the vehicle or version entries? Something like:

modules:
  BCM:
    address: "745"
    response: "765"

If that's welcome I'll follow up with the Nissan and Infiniti map. If you'd rather keep the schema as it is, no problem, and this PR stands as just the two entries.

I'd rather ask than push a schema change unannounced. Also opened #1 about the licence, which is the other thing between me and contributing more of this.

[mmsaki]

Scanned the car, so this now carries a real ECM identity rather than a TODO.

Worth writing down what this generation actually does, because it caught me out:

UDS identification is rejected outright. Every 22 F1xx returns 7F 22 80, and 10 03 (extended session) returns 7F 10 12. So F18A Supplier and F187 Part number — the fields your schema's ecu: line wants — are unavailable on a 2011 Renault-Nissan module.

Nissan's Consult block answers instead. 21 83 returns a fixed layout: 5-byte ASCII spare-part number, then supplier, hardware, software, edition and calibration numbers. Six modules answered:

Address	Module	Spare part number
7E0	Engine (ECM)	1VW3C
7E1	Transmission	X457E
745	Body control	1V47B
747	Infotainment	1UF0A
74D	Power distribution (IPDM)	JA000
752	Airbags (SRS)	JK83C

I've put Nissan/1VW3C on the ECM. Two things I deliberately didn't do:

• I didn't synthesise the full part number. Nissan ECMs carry a 23710- family prefix, and it's near-certain this one is 23710-1VW3C, but the module doesn't report the prefix and I'd rather record what was read than what was inferred.
• I didn't invent a supplier. Nissan there is the OEM, not whoever built the ECU. If you'd rather that field stay strictly supplier/model, say so and I'll move the part number somewhere else — a part_number field would fit this whole platform family.

The other five modules have nowhere to go under the current schema, which is the same gap as the address question above. They're listed here so the data exists somewhere public even if the schema never takes it.

[autodiag2]

Hello thanks for your contributions !

• Module addresses
  I've introduced configuration in the vehicle version, this feature better match the reality, a vehicle version config has one ECM, ABS etc
  with protocol you can define address and response it is extensible with any text field eg:
  protocol:
  can11bit:
  address: 7E0
  response: 765
  otherfield1: some
  anotherfield: some
  kwp2000:
  somefield: some

• Identity responses
  I will not integrate this for now because I don't have enough data but it looks like integrating non standard request decoder in database, it may be a good point !

• A protocol quirk
  can be easily encoded in your scantool but putting it in the database require applications flow eg. readDTC -> UDS readDTC -> KWP readDTC
  same as previous it is not ready for that

  • part number instead of ecu model, the database is resilient over that and putting under Nissan/partnumber is just a small approximate but on the scantool side it means that have to compare part number against ecu model a bit missleading ...

  also i've merged your branch but of course if you want to continue contributing to proto specific information your work is welcome