Heavily document `Sensitive` and `Deferred` requirements

[sgnn7]

Old documentation did not go into necessary depths to ensure that the user was provided with all the necessary information about how the Deferred and Sensitive chaining work and why they are critical in ensuring secure use of credentials. This PR ensures that we do that and fixes some outdated examples.

What ticket does this PR close?

Connected to #198

Checklists

Change log

• [ ] The CHANGELOG has been updated, or
• [x] This PR does not include user-facing changes and doesn't require a CHANGELOG update

Test coverage

• [ ] This PR includes new unit and integration tests to go with the code changes, or
• [x] The changes in this PR do not require tests

Documentation

• [x] Docs (e.g. READMEs) were updated in this PR, and/or there is a follow-on issue to update docs, or
• [ ] This PR does not require updating any documentation

[alexkalish]

@sgnn7: I'm not sure that I understand why the double unwrap is needed. Could you explain a bit more?

[sgnn7]

@alexkalish If you only have one Sensitive wrapping which is the default one for the secret returned by Conjur, if you print out the deferred method value, it will dump any parameters raw onto the console (including the API key and hostname when you use the long form of the signature). If you only have the single wrap but in the flipped places (have it on the method invocation itself), you will be able to print out the raw fetched secret to the log. Since we want neither, we have to wrap both the invocation and the retrieved value in the Sensitive type.

[sgnn7]

@alexkalish : @diverdane and I talked about this and since we require the API key to be Sensitive type already (and other params are not privileged), the double wrap seems unnecessary in the guidance. I am updating the documentation to reflect the new usage recommendation that does not require the .unwrap.unwrap.