Fix contradiction in icount description. (#665)

* Fix contradiction in icount description.

Specifically, after we added the pending bit, the description of a
possible 1-bit implementation of this register was not updated. As a
result the count description said that decrementing resulted in a
trigger, while in the introductory part we said that decrementing
resulted in pending getting set.

Rewrote it a bit, so it's hopefully easier to read.

Fixes #662.

* Explain 2 icount use cases.

Are there others? Is this clear?

* eret is now mret

Co-authored-by: Paul Donahue <48959409+pdonahue-ventana@users.noreply.github.com>

* Language

Co-authored-by: Paul Donahue <48959409+pdonahue-ventana@users.noreply.github.com>

* Small clarification.

* Move single step example code into Appendix.

* Language cleanups.

* Make things less ambiguous.

Remove explanation about how icount can be done in a single bit.

The single-bit implementation can work, but only if you tie all mode
bits together and have max count of 1. If all mode bits are enabled
together, there is no case where the existence of a pending bit can make
a different. But this is only useful for an external debugger, and we
already say that for external debuggers dcsr.step is the preferred
solution.

For native debugging, the least hardware I can think of is 2 bits,
because there are effectively 3 states: disabled, pending, and enabled.
This assumes the mode bits are tied together in such a way that there is
only one sensible option. I'm not sure if that's even worth mentioning
anywhere. It would be a long explanation with little benefit.

* Clarify the icount always decrements.

Even if the chosen action cannot be taken.

Also use proper field macros for most action=0 instances.

* Refer to precise instructions in icount.count.

Co-authored-by: Paul Donahue <48959409+pdonahue-ventana@users.noreply.github.com>