Move vdrtools fork under aries-vcx repo

[Patrik-Stas]

I'd like to suggest moving the fork of vdr-tools into this repo. We currently using fork of vdrtools, eg:
https://github.com/hyperledger/aries-vcx/blob/0.50.0/aries_vcx/Cargo.toml#L40

Given good developments toward credex libs migration and commitment to drop usage of libindy/vdrtools in 2023, in combo with the fact there's no updates for the library from Evernym https://gitlab.com/evernym/verity/vdr-tools I think we can continue taking lead within our fork, but move the development here, rather than having it externalized and less transparent on some gitlab repo.

As underlying code for holder, prover, verifier works with credex libraries, large portions of the vdr-tools codebase can technically be deleted today (with some updates to libvcx codebase to start using credex/indy-vdr codepaths by default). By the end of the journey, the only thing which should be left out of vdrtools is wallet implementation, which might be then superseded (or might be used interchangeably) by (or with) Aries Askar.

Additionally having git dependency would become a problem once we attempt to publish aries-vcx as crate (this was touched on at the last aries-vcx call)

@mirgee @gmulhearn what do you think?

[gmulhearn]

No immediate issues come to mind - could be a good move if the plan is to move away from vdrtools. Will be convenient with some of the dependency issues we know we'll likely have to solve.

I'd be interested to see how IDEs perform with this change. I wonder if it will impact performance having the giant vdrtools repo 'open' at all times when working in the aries-vcx workspace?

[Patrik-Stas]

I am confident M1 users won't notice ;-) But on slower machines, I guess depends on IDE, both performance and possible solutions. in InteliJ for example you can exclude directory from being indexed. Not sure if users of other IDEs might run into an issue.