RFC: Lazier and more interface-based conversion

Rather than trying to convert and copy values between Python and Julia, I propose to:

1. Enhance pyjlwrap and implement most of Python data model such that virtually all Julia values are usable with pyjlwrap. For example, we can translate getindex to __getitem__ etc. such that we can use an AbstractArray without translating it to a Numpy array. We can also implement __array__ in Julia side to make numpy.asarray fast.

2. Restrict automatic conversion to Julia types which supports ("practically") lossless round-trip (Julia -> Python -> Julia). Maybe something like:

Union{
    Nothing,
    Integer,
    NpyNumber,  # Int64, Float16, Float32, Float64, ...
    Array{<: NpyNumber},
    String,
    Dates.AbstractTime,  # or maybe only the concrete subtypes
    IO,                  # ditto
}

Here is a reference implementation that shows this approach works: https://github.com/tkf/PyBase.jl

It would solve, e.g.,:
https://github.com/JuliaPy/PyCall.jl/issues/11
https://github.com/JuliaPy/PyCall.jl/issues/175
https://github.com/JuliaPy/PyCall.jl/issues/507
https://github.com/JuliaPy/PyCall.jl/issues/555
https://github.com/JuliaPy/PyCall.jl/issues/616
https://github.com/JuliaPy/PyPlot.jl/issues/391
https://github.com/JuliaPy/PyPlot.jl/issues/400
https://github.com/JuliaPy/pyjulia/issues/122
https://github.com/JuliaPy/pyjulia/issues/123
https://github.com/JuliaDiffEq/diffeqpy/issues/21

There are many details that can be refined (e.g., rather than using a single Python class, maybe define a few base class? Or even create Python class on-demand?) but first I'd like to know if it is a reasonable direction for PyCall.jl.

まず既存の pyjlwrap のアプローチと、リンクされている PyBase.jl のリファレンス実装を確認し、次にそれらを一覧にある変換関連の issue と比較します。提案されているインターフェースベースの変換方針が PyCall.jl に適しているかを明らかにし、実装前にその範囲を具体化できれば完了です。