Remove the TArray related docs

[rikhuijzer]

From a comments by @yebai in TuringLang/Turing.jl#1778 (comment):

By the way, soon we can also remove the TArray related docs since the new Libtask can deep-copy heap-allocated objects - we still need to activate it. See

Libtask.jl/src/tapedfunction.jl

Line 309 in 4a85b47

# ?? should we deepcopy Array and Dict by default?

[yebai]

After #129 is complete, we can depreciate all T* data structures, and create a switch for enabling _binding_copy for all Julia types.

[yebai]

@rikhuijzer would you like to give it another go to depreciate all the TArray and TRef data structures? The new tape_copy API now allows us to copy objects of any user-specified types.

[rikhuijzer]

@yebai I won't be able to pick that up in the near future unfortunately

[yebai]

@KDr2 let's create a PR to depreciate all the TArray / TRef APIs, and suggest to the user to use Array and Ref as a replacement. Then we can switch on deep-copying behaviour for Array and Ref types by default.

[yebai]

Then we can switch on deep-copying behavior for Array and Ref types by default.

For backward compatibility, e.g. this example in README, maybe we can consider a keyword argument to the TapedTask constructor, i.e.

# Default option: when `deepcopy` is empty, then we don't perform deep copy for any types
TapedTask(...; deepcopy=[])

# Switch on deep copy behavior for Array, Dict, Ref
#  Need to update AdvancedPS to explicitly specify `deepcopy` 
TapedTask(...; deepcopy=[Array, Dict, Ref])


# In order to implement `tape_copy` for this design, we might need to 
#  dispatch on `TapedTask` instances, e.g. 

tape_copy(Val{tapedtask}, ...)

[KDr2]

a keyword argument to the TapedTask constructor

If we do this, we should add the same argument to TapedFunction and tape_copy? if so, it's not very clean I think.

tape_copy(Val{tapedtask}, ...)

I don't understand this, now we only tape_copy values in bindings.