The directive processor can add a newline to assets. If it comes after the default source map then this line is not accounted for when determining line offsets.

Adding a new line with semi-colons can cause off by 1 errors with source maps. Instead we want to add a semicolon. If the last character was whitespace such as a newline, we want to make sure that there are the same number of `str.lines` before and after, so we replace the whitespace character with a semicolon followed by the same whitespace character.

The calculation of length of asset is done by counting semicolons, however not all mappings end with a semicolon. When they do we must increment the offset.

The next part is harder to explain. 

We concatenate two assets A.js and B.js. A has 10 lines B has 5 lines.

After we’ve done this we want an offset that looks like this:

```
A.js: {"line"=>0, "column"=>0}
B.js: {"line"=>11, "column"=>0}
```

To get 11 we take the prior length of mappings for A.js which is 10 (from the lines) and increment by one to get to 11.

Now we add another asset C.js which has 2 lines. We want an offset that looks like this

```
A.js: {"line"=>0, "column"=>0}
B.js: {"line"=>11, "column"=>0}
C.js: {"line"=>16, "column"=>0}
```

If we add the last offset which is 11, to the length of the asset of B (which is 5) then we get the correct offset which is 16. We do not have to add an extra +1. 

I think this was accidentally working previously based on unwanted behavior from adding semi-colons and newlines.

This patch preserves an original source maps if one was present.

```
Warming up --------------------------------------
              count
   317.318k i/100ms
              length   329.512k i/100ms
              size     329.953k i/100ms
Calculating -------------------------------------
              count       9.806M (± 7.7%) i/s -     48.867M in   5.014627s
              length     11.696M (± 6.3%) i/s -     58.324M in   5.008040s
              size       11.074M (± 7.5%) i/s -     55.102M in   5.005626s
```

Based on the spec it is not guaranteed that there will be a mapping for each and every line https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/gp_ULp-h1fQ

We were previously using this behavior to know the length of a previous asset when concatenating source maps. 

We can get around this by storing the length of the previous asset in an “x_sprockets_linecount” key. This is guaranteed to be on the asset since it is added by the `DefaultSourceMap`.


We no longer need to offset the first asset by one line. This was accidentally working before.

We no longer add a newline if one did not previously exist.

travis-ci/travis-ci#8408 (comment)

Previous test was failing intermittently with results like `["0", "0", "1", "1", "0", "0", "1", “1”]`

We need this because `concat_source_maps` expects a `x_sprockets_linecount` key in the map metadata. It wasn’t put there until this PR, so if a map gets pulled out of the old cache and attempts to get loaded into memory then it will fail.

By rev-ing the cache we can ensure the key will be there, since it’s added by `DefaultSourceMap`.

So we can take advantage of the UTF32 encoding.