Use GFM syntax for code block
Revert "Include intercept option in expandMatrix()"

This reverts commit 39d3d2bcb42ceb799ff33a29c1e97049dee96a32.
Add explicit R frontend to expandMatrix()

It was a hassle to insert an intercept and set the row/column names in
C++, so these are now done in an R wrapper.  The C++ backend has
accordingly been renamed `computeExpandMatrix`.
Extend predict functions to logistic models

Closes #6
Extend marginal effects to logistic models
Add test of predict computations
Fix typo in model.frame.polywog() documentation
Include weights when extracting model frame
Rewrite bootstrap and fitting functions

Unfortunately, this has to be done as an omni-commit due to
chicken-and-egg problems.  The backend functions `fitAdaptiveLASSO()`
and `fitSCAD()` were rewritten in anticipation of the additional
arguments to `polywog()`; either would have been broken without the
other.  Along the way, I also did a bunch of cleanup (closes #8,
incidentally), cut down on code rewriting, only compute the
polynomial-expanded model matrix when necessary, etc., hence the large
amount of file-by-file changes.

This commit also wipes out the now-defunct `polym2()` and `rawpoly()`
functions, all of which are implemented better (and more readably) in
C++ code.

Changes to the bootstrap are also implemented here since `bootPolywog()`
is tied so closely to `polywog()`.  However, this commit does break
`cv.polywog()`.
Rewrite cv.polywog()
Add test of cv.polywog()
Add test of logistic models
Link to Github repo in documentation
Write up predVals() changes in NEWS
Convert NEWS to Markdown
Fix typo
Change default thresh/maxit in bootstrapping

Previously, the default was to use the same default as in `polywog()`,
depending on the penalization method used.  But that required clunky
code like

```r
m1 <- polywog(y ~ x, thresh = 1e-10,
              control.boot = control.bp(thresh = 1e-10))
```

in order to make the bootstrap behave the same as original fitting.
The new behavior (which requires adding `thresh` and `maxit` elements to
`"polywog"` objects) makes this easier.  (As a bonus, it also results in
more aesthetically pleasing code in the examples, where relatively high
thresholds have to be used in order not to run afoul of CRAN's
computation time requirements.)
Reduce computation time of examples
Merge bootPolywog() and control.bp() documentation
Fix typo in margEff.polywog() documentation