drop RCall dependencies and more refactoring

In the current implementation of JuliaCall, RCall.jl is required for converting objects between R and Julia environments. While it may be sufficient for most operations, it does however lead to some performance bottlenecks and creates difficulties in maintenance. For instance, any upgrades in RCall may unintentionally break JuliaCall. I reckon that we should drop RCall dependencies and implement our own conversion procedure. It allows us

1. to significantly improve setup time
2. to easily maintain as the implement is independent to RCall (of course, we want to make sure JuliaCall is compatible with RCall).

The conversion code could be written in a similar manner as
https://github.com/armgong/rjulia. rjulia requires an installation of Julia in the build time. It could be potentially difficult for non-techinical users and it also makes CRAN submission difficult. Via my PR #22, the shared library is loaded at runtime and no julia instllation is needed. As a result, users could download a binary version from CRAN directly.

It could be a major refactoring. Instead of working on the current version of JuliaCall, I suggest we should start a new organization, hypothetically juliaverse

At RJuliaCall juliaverse, we split the JuliaCall into sub-packages

1. juliaapi
   this package basically just expose the julia C api and allows developers to manipulate julia. It will be basically what I have done in #22

2. juliabase
   this package depends on juliaapi and supports conversions of julia base types. For example, conversions between julia Array{Float64} and R numeric().

3. juliadata
   It supports the packages at https://github.com/JuliaData

4. juliaverse
   It is a mega package containing all the above packages + additional supports, e.g. jupyter. (I personally prefer lower-cased package name and it seems it is also the common practice nowadays to use lower-cased package name)

@Non-Contradiction what do you think about the plan? I also want to bring in @armgong since we will probably use some code in rjulia.

Start by reviewing the current RCall dependency and the work described in PR #22, then compare the proposed approach with rjulia. The issue proposes a major split into juliaapi, juliabase, juliadata, and juliaverse, so completion would require an agreed architecture and implementation plan before coding can begin.