Object shared references architecture

This is a meta-issue to cover a few different discussions on mutability patterns.

#112 and https://github.com/dgkf/R/pull/123#discussion_r1558402942 have me feeling like now might be a good time to think more holistically about how objects are referenced and mutated. While getting this project off the ground, clones were used generously and it's time to be more thoughtful about minimizing those.

Overall, I think we're on the right path right now, so if you're already up to date on those discussions, this is probably more of a summary than any novel plan. I'll collect the ideas that are leading us to where we are:

## Environments of ***shared*** objects

Environments should be a collection of `Rc`, allowing multiple references to exist to the same data. A trivial example like:

```r
y <- x + x + x + x + x
```

Should never copy the data in x.

- [ ] Convert `Environment>>` to `Environment>>>`

## ***mutable*** objects

Mutable objects should, by default, use `Rc::make_mut`, providing copy-on-write to objects whose mutability does not change the internal representation of the data.

In the following example:

```r
x <- y <- c(1, 2, 3)
x[2:3][[1]] <- x[[1]] + x[[3]]
```

First, the right-hand-side is evaluated using `x[[1]]` and `x[[3]]`, producing a result using only references to `x`. The left-hand-side needs to first be made into a mutable reference before producing a subset and updating the value using assignment.

I anticipate that the way subsetting operators work might need to change to accommodate this, perhaps `Rc::make_mut` needs to be called when `x` is first accessed, given that it is on the left-hand-side of the assignment.

- [ ] Update `Rep`s to make use of `Rc` and `Rc::make_mut` for managing mutability (#112)
- [ ] Update assignment to an expression (subset, etc) to make the object mutable on first access, not after subsetting.

## ***mutable*** object ***representations***

And finally, when an object has multiple representations, and its representation needs to change (for instance, materializing a range into a vector), these representations should be behind a `RefCell>`

```r
x <- 1:100
x[[3]] <- 10 # can no longer be represented as a range, materialized as vector
```

- [ ] Update `Vector` (#112)

Start by reading issue #112 and the linked pull-request discussion, then review the Environment, Rep, assignment, and Vector areas named here. The work is complete when shared objects use reference counting, mutable access follows the proposed copy-on-write behavior, assignment expressions handle mutability correctly, and changing representations is supported.

Written by the indexing model from the issue text.