Highlight extra required methods for iterators

[cmcaine]

A student on exercism read this section and did not realise that they had to define at least one of Base.IteratorSize and length.

I'm not totally happy with this revision, but it does seem a bit clearer to me. Some particular bits that I think could be better:

• eltype is called a required method, but that's only sorta true because the default definition is probably fine.
• it's a bit long?
  • Maybe one big table with columns "Must be defined if", "Method", "Default definition", "Brief description" would be better, but it would be quite wide.

Because the visual appearance of the docs isn't totally clear from the markdown, here are before and after images.

Before:

After:

Another variant option (one big table for all conditionally-required methods):

Source for the variant option

There are two methods that are always required:

| Required method        | Brief description                                                                        |
|:---------------------- |:---------------------------------------------------------------------------------------- |
| `iterate(iter)`        | Returns either a tuple of the first item and initial state or [`nothing`](@ref) if empty |
| `iterate(iter, state)` | Returns either a tuple of the next item and next state or `nothing` if no items remain   |

There are several more methods that should be defined in some circumstances. Note that 
because the default definition of `Base.IteratorSize(IterType)` is `Base.HasLength()`, you should define at least one of `Base.IteratorSize(IterType)` and `length(iter)`.

| When should this method be defined?                                            | Method                          | Default definition | Brief description |
|:--- |:--- |:--- |:--- |
| If default is not appropriate                                                  | `Base.IteratorSize(IterType)`   | `Base.HasLength()` | One of `Base.HasLength()`, `Base.HasShape{N}()`, `Base.IsInfinite()`, or `Base.SizeUnknown()` as appropriate                                                                     |
| If `IteratorSize(IterType)` returns `Base.HasLength()` or `Base.HasShape{N}()` | `length(iter)`                  | (*undefined*)      | The number of items, if known                                                                                                                                                    |
| If `IteratorSize(IterType)` returns `Base.HasShape{N}()`                       | `size(iter, [dim])`             | (*undefined*)      | The number of items in each dimension, if known                                                                                                                                  |
| If default is not appropriate                                                  | `Base.IteratorEltype(IterType)` | `Base.HasEltype()` | Either `Base.EltypeUnknown()` or `Base.HasEltype()` as appropriate                                                                                                               |
| If default is not appropriate                                                  | `eltype(IterType)`              | `Any`              | The type of the first entry of the tuple returned by `iterate()`                                                                                                                 |
| If iterator is stateful                                                        | `Base.isdone(iter[, state])`    | `missing`          | Fast-path hint for iterator completion. Should be defined for stateful iterators, or else `isempty(iter)` may call `iterate(iter[, state])` and mutate the iterator. |

[cmcaine]

I included two variants above. The PR represents the first one (screenshot 2). Since writing the PR I've come to think that the second one (one big table for all conditionally-required methods) is better (screenshot 3).

But now that this has a review and a merge-me tag, it seems rude to change the PR unilaterally. So, whoever comes to merge this, please consider the second variant above (code and screenshot is in the first post).

[LilithHafner]

This is an improvement, so I'm going to merge it now.

Separately, as a PR author IMO you are always allowed to make unilateral changes to your PR. And, if you still prefer something else over the current state of this PR, feel free to make another one to change this documentation again.

[cmcaine]

Cool, thanks. Please consider merging my follow-up PR on this topic: #50994