Solr bug fix

See merge request !51

Add BSD-3 Clause license

Closes #5

See merge request !50

FIX CWPT-475: Remove extra spaces in external links around nonvisual-indicator span, breaks ::after

See merge request !49

FIX: Stop the default SolrSearchIndex from using addAllFulltextFields()

Currently, all CWP sites are given a default `SolrSearchIndex` implementation, which is supposed to be a simple-but-correct implementation of Solr search.

Unfortunately, this isn't compatible with recent versions of the CWP Basic Recipe which includes the `contentreview` module.

The old implementation called `SolrIndex->addAllFulltextFields()` which is a convenience method to include all full-text fields on a given class(es), however the `contentreview` module adds text fields to `SiteTree` such as `LastEditedByName`. These get included in the Solr index, and end up doing weird things (e.g. now you can search a website for someone's name and see all the pages that they've edited). `addAllFulltextFields` is a nice convenience method, but we shouldn't rely on it for `cwp/cwp-core` module, as who knows what other modules will be included on top of the basic recipe, and who knows what text fields they'll add to objects.

Paired with a merge request to the `cwp/cwp` documentation to note this change within the docs (cwp/cwp!157).

See merge request !48

Remove support for solr-3 and legacy.

This cannot go through the normal recipe deprecation cycle, since CWP
infrastructure no longer supports solr version 3.

See merge request !47

This cannot go through the normal recipe deprecation cycle, since CWP
infrastructure no longer supports solr version 3.

Push all logs to syslog, to ensure exceptions are captured.

Requires https://github.com/silverstripe/silverstripe-auditor/pull/7

Here is some example logs:
```
Aug 25 09:50:20 rabarbar.local SilverStripe_log[80610]: ERROR: talk to me! (line 143 in /Users/muzdowski/Sites/cwp-installer/framework/control/Controller.php) ["extra!"]
Aug 25 09:50:38 rabarbar.local SilverStripe_log[80612]: ERROR: Uncaught Exception: e (line 552 in /Users/muzdowski/Sites/cwp-installer/cwp/code/pagetypes/BasePage.php) []
Aug 25 09:50:56 rabarbar.local SilverStripe_log[80613]: WARNING: mysqli::mysqli(): MySQL server has gone away (line 77 in /Users/muzdowski/Sites/cwp-installer/framework/model/connect/MySQLiConnector.php) []
```

See merge request !45

Remove custom auditor code and replace it with silverstripe/auditor mod.



See merge request !44

Portal uses LDAP with "Login" field for login. Support that in logger.



See merge request !43

API enable password change notifications via email

Fixes https://silverstripe.atlassian.net/browse/CWP-878

See merge request !42

FIX: Fix initial dev/build on PDO Database.

When the database isn’t yet created, $current is set, but
$current->currentDatabase() is empty. I suspect this only applies to 
PDO connections. It results in errors during startup.

This check fixes it.

See merge request !41

When the database isn’t yet created, $current is set, but
$current->currentDatabase() is empty. I suspect this only applies to 
PDO connections. It results in errors during startup.

This check fixes it.

Improved CwpLogger audit functionality

Followup action from a past incident where the lack of logging (in particular page deletion) made us less efficient in analysing a sequence of events leading to lost page data.

See merge request !40

Note that an "archive" is tracked as delete -> unpublish -> delete in the audit logs,
due to the way the functionality is implemented in core. There's no way to tell
those operations apart on the extension hook level.

- delete
- duplicate
- revert to live

Extension hooks were generic enough (e.g. using Versioned or Hierarchy)
to be used in other contexts as well - for example logging publication of
custom versioned DataObject subclasses.

Audit logs for auto-logins (restoring existing "remember me" session)

Creates more noise in the logs, but realistically the current log auditing isn't really cutting it - you want to know which user has been active on the system on a given day, not when they happened to click "remember me" the first time, right?

See merge request !39