prop340: clarify SENDME window accounting

See merge request tpo/core/torspec!265

prop340: Expand on why we don't allow DATA fragmentation

See merge request tpo/core/torspec!264

Slight clarifications about hsv3 relay crypto

See merge request tpo/core/torspec!261

I was going to propose allowing DATA fragmentation, but I think I've
talked myself out of it. I think it'll be useful to have a record of
this line of thought for future reference.

cert-spec: Put backticks around SIGNATURE

See merge request tpo/core/torspec!263

See !259

Rename "text vectors" to "test vectors" for correctness.

See merge request tpo/core/torspec!260

There was a missing link at one point, and another point where we
should have said what cryptography we were using.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Clarifications about INTRODUCE1/2 extensions

See merge request tpo/core/torspec!255

Prop#349: Command state validation

See merge request tpo/core/torspec!257

Completely ignore unknown hspow-params

Closes #256

See merge request tpo/core/torspec!256

hspow: Clarifications to scheme and descriptor Item

See merge request tpo/core/torspec!254

I got the answer to this question from
  proposals/324-rtt-congestion-control.txt

(This thing should have a proper identifier, not merely a descriptive
phrase, but that may be controversial.)

This sentence seems stray in this section.  The information is alreayd
present with the wording

  The same rules for multiplicity, ordering, and handling unknown types
  apply to the extension fields here as described \[EST_INTRO\] above.

which appears earlier, for each of the two sections.

The text uses "scheme" and "version" a couple of times.  The formal
protocol says "type".  The terminology should be consistent.  IMO
"scheme" is the best word to use.  "version" is particularly bad.

Change all references to "type" and "version" to "scheme".

Revise the INTRO1_POW_EXT section

See merge request tpo/core/torspec!253

There were two different versions of this description in the doc, and
they were both wrong in different ways. One was newer and implied the
extension was encoded outside the encrypted section (it's inside). The
other was older and had some outdated references and recommendations
from when this was still a proposal, but it was in the correct location.

I consolidated the two and made the correct location of the extension
explicit.

Proposal 340 clarifications

See merge request tpo/core/torspec!252

Replace "payload" with "body"

See merge request tpo/core/torspec!248

Clarify rend-point behavior with relay cells

Closes #254

See merge request tpo/core/torspec!250

Beautify the table of relay commands

See merge request tpo/core/torspec!249

Previously, we didn't actually say that relay cells got
retransmitted; we only said that the circuits were "joined".

Closes #254 by clarifying that RELAY_EARLY cells are retransmitted
as RELAY cells.