Implement updated LazyOption type

[austinabell]

Currently, the LazyOption type lives within collections and just behaves as a wrapper around accessing a key/value pair in storage. The benefit to updating this API to have a caching layer in-between is that on multiple gets or sets, the storage does not need to be read and written to multiple times, and only needs to be updated once the variable is dropped out of scope.

Reference for what this API would look like can be seen in #409 where the Lazy type is implemented.

For comparison, both Lazy<T> and LazyOption<T> represent values lazily loaded from storage, where the following should be assumed and have as close of an API as possible:

Lazy -> T
LazyOption -> Option<T>

The difference is just that Lazy assumes the value at the key is always set, where LazyOption behaves like an option where the value can be None.

The criteria of this issue will be as follows:

• This new data structure will live under the store module, along with Lazy
  • The old API should not be removed yet, as we want to migrate over without breaking changes and not enforce people to use the unstable feature which the near_sdk::store module is under
• This type should be able to Deref (and DerefMut) into an Option<T> which will load the value from storage, and allow all APIs from Option to become available
  • The API on the structure itself can probably mimic the Lazy type very closely
• During the lifetime of the variable, storage should only be read max once and written to once.
  • The only exception should be if the flush method is exposed and called to update the storage early, to get storage changes, but the updated value should be kept in the cache so will still never read more than once.

[ChaoticTempest]

Closed with #444