Adjust policy-like security and privacy assertions

[mmccool]

Action for item 4 in w3ctag/design-reviews#736 (comment) for Architecture.
Overlaps with other issues (todo, add links here) that will look at entire document. However, this issue will document issues in Security Considerations and Privacy Considerations that may need adjusting specifically, after review by the Security TF.

Note: we want to remove (or modify) assertions that specifically can only be asserted about deployments, not implementations. However, there are many assertions in architecture that can be read as requirements for other specifications, such as TD. To the extent that those specifications satisfy the requirement, we can consider them true. In other words, if they are verifiable at the point of implementation, we can keep them.

Assertions that need adjusting:

• arch-security-consideration-no-private-security-data - redundant with arch-security-consideration-public-metadata-only, and does not mention extensions.
• arch-security-consideration-other-programming-mechanisms - not inside a mitigation, too general, does not use RFC-2119 keywords: turn into informative text
• arch-security-consideration-isolation-sensitive and arch-security-consideration-isolation-tenants both require strict isolation of WoT runtimes, but while this would be a very useful property is difficult to achieve and goes beyond the requirements for a runtime, but rather affects how a runtime is instantiated (eg. in secure containers, etc). So it's a deployment issue, not an implementation issue, per se. Also perfect isolation is still hard to achieve with current technology, so probably asking for too much. Downgrade to informative statements.

10.2.2, 10.3.1: keep assertions, conceptually about an implementation, but will need manual assertions.

10.3.2: "should guarantee isolation of" -> "SHOULD isolate"

10.4: should not be a problem to validate. Note however that static IPs may be necessary to set up certs on LANs. Also applies to 10.5. Assertion for "implicit access control via access to a common network" should be changed to a MUST.

10.5: ok as is

11.1.1: may overlap some with assertions in TD spec, but for now will just look at these in-place. "this specific issue" -> "these specific issues". Last assertion should be changed to "As a matter of policy, ..." and made informative.

11.2: verifiable, but may overlap with some assertions in the TD spec. Check for overlap (and conflict) with TD assertions.

The following are requirements of specifications, and not assertions about implementations per se. We MAY want to find another way to express these rather than using RFC-2119 Assertions.

[mmccool]

Reviewed in security TF, now need to implement with a PR...