[n64-jp-1.1] CIC6105.c matched

[AngheloAlf]

Matches the jp version of CIC6105.c

I matched this file (among a few others) a few months ago while testing the multiversion support.

There are a few open questions:

• How do we want to handle version checks when something is added/removed? >= VERSION/>/</<=?
• CIC uses references a specific rsp ucode cic6105TextStart. Where do we want to put those externed symbols?
  • In CIC6105.c: It is only referenced here, but it goes a bit against our conventions to put externs in a .c file.
  • CIC6105.h: I guess could be fine?
  • ucode.h: A libultra header with other rsp ucode syms. The main disadvantage I see is polluting libultra headers with game specific syms. (But I touched the mbi.h file 😅 )

[hensldm]

* How do we want to handle version checks when something is added/removed? `>= VERSION`/`>`/`<`/`<=`?

Personally I like the idea of always using >= showing which version the code was added, and always using < showing which version the code was removed.

* CIC uses references a specific rsp ucode `cic6105TextStart`. Where do we want to put those externed symbols?
  
  * In `CIC6105.c`: It is only referenced here, but it goes a bit against our conventions to put externs in a .c file.
  * `CIC6105.h`: I guess could be fine?
  * `ucode.h`: A libultra header with other rsp ucode syms. The main disadvantage I see is polluting libultra headers with game specific syms. (But I touched the `mbi.h` file 😅  )

For reference OoT puts it in ucode.h and I would say just put it there for parity.