Proposal to refactor Span.

### Why Span?

* For error reporting.
* For source mapping.

### What does Span look like now?

* A Pest Span:
* Shared source string.
* Start and end indices into string.
* An optional source file path.

### What is this structure currently good for?

* Error reporting. Everything is very handy. Even without the path.

### Bad for?

* Source mapping:
* Requires path, and for start and end to be file offsets.
* IR:
* Not every error producing value has a known span.
* (De)serialisation prefers path + indices, does not want to (de)serialise source strings.

### A solution?

* Remove Pest span and make the path mandatory:
* Source mapping is happy.
* If no path is applicable then one cannot create a Span, so the whole Span must then be Option, or we have an 'official' or 'default' empty/null Span.
* IR (de)serialisation is simplified.
* Make spans optional for error reporting:
* IR can create errors without Spans. Note, this would hopefully be pretty rare. The IR would try very hard to provide a Span when asked but can't _guarantee_ a Span, and therefore must be optional.
* Source mapping doesn't care.

No file or test is named. Start by locating the Span definition and tracing its uses in error reporting, source mapping, and IR serialization. Done means agreeing on the replacement representation, including whether spans are optional and how paths and indices are handled.

Written by the indexing model from the issue text.