Merge vdsuite NID database to the vitasdk

[devnoname120]

Follow-up of #390.

Use this script: https://github.com/devnoname120/vitasdk-db-tools/blob/master/dbtools.py
Database: https://bin.shotatoshounenwachigau.moe/vdsuite/ghidra-loader-db.yml

I converted this database to a nids.txt format for converting it more easily:
ghidra-loader-db.txt

[Princess-of-Sleeping]

I disagree with this.
Above all, vitasdk and vdsuite db already use different function names.
And added by using script -> vitasdk to broken again.

[devnoname120]

I won't overwrite function names where it doesn't make sense.
My previous iteration (#390) that merged 3 databases didn't cause any regressions and didn't break any homebrews compilation.

[Princess-of-Sleeping]

known problem

1. vdsuite uses the official name as much as possible, but vitasdk does not.
   This case, Which would you choose?

2. Removed "k" sce.
   vdsuite decided to use sce instead of ksce even for kernel functions. So need update Travis script.

But, if you ignore 1 and 2 and added them, everything will be mixed and maintenance will be very difficult.

[Princess-of-Sleeping]

And you made the wrong addition using a script.
https://github.com/vitasdk/vita-headers/pull/390/files#diff-f18ad1cb18f3d08fc815f05fda7da0ed3d15e0b2acd35e20e64c0ad9bc02697cR473-R483

[devnoname120]

Both 1 and 2 are covered in the script: https://www.github.com/devnoname120/vitasdk-db-tools/tree/master/dbtools.py

It uses a db_lookup.yml file as a reference to make sure to add to the right modules/libraries and ignore all the unknown NIDs.

Which function was incorrectly added?

[Princess-of-Sleeping]

      SceAppUtilBook:
        nid: 0xDA27A9D3
        kernel: true
        functions:
          ksceAppUtilBookMount: 0xFDAAF091
          ksceAppUtilBookUmount: 0x9C1794C2
      SceAppUtilAddcontForce:
        nid: 0x9D061921
        kernel: true
        functions:
          ksceAppUtilAddcontForceAddcontMount: 0x6087E5F7

These functions are user functions, but in pull/390 they were added as kernel functions.

[devnoname120]

@CelesteBlue-dev Any ideas why your nids-extract tool returns kernel: true for these libraries?
I used this tool to build the reference db_lookup.yml that I used to extract library names, kernel status, etc.

@devnoname120 I forgot a condition (modattribute & 0x7) in nids-extract. It is now fixed in ps-nids-extract.

[devnoname120]

@CelesteBlue-dev Great! Feel free to take over this idea. You can base it off the script I used in my other PR.