Color space is not saved on the graphic state stack

[dhdaines]

The color spaces for stroking and non-stroking operations are part of the graphics state, but pdfminer.six doesn't treat them that way for some reason. This frequently leads to errors which go unnoticed because they are suppressed without settings.STRICT. For instance in https://github.com/jsvine/pdfplumber/blob/stable/tests/pdfs/nics-background-checks-2015-11.pdf (the test PDF for lots of pdfplumber tests) the content stream defines a color space (with 3 components) as /Cs1, then does stuff like this in the content stream:

q
% some stuff
/Cs1 cs 0.8 1 1 sc
% note, 3 components + sc
Q
% graphics state is popped, we should restore the default color space (which is DeviceGray)
1 sc
% oops! pdfminer thinks we're still in /Cs1 which takes 3 components

There are two bugs here:

1. PDFGraphicState doesn't have default colors when created. But according to the spec (and like basic common sense, duh) these are DeviceGray and 1.0 (i.e. black).
2. PDFPageInterpreter stores the stroking/non-stroking color states as attributes of the interpreter instead of putting them in the graphic state.

Ideally, colors and color states should never be None in an LTComponent (because anything that gets drawn, gets drawn in a color...) but in practice because of these problems they frequently are.