* docs: split changelog into separate file
See #137
* docs: add information to Plugin header
Fix#138
* docs: update WP readme
* docs: remove FAQs
* docs: remove installation instructions
These were causing the FAQ section to render incorrectly
when viewed in the [preview validator][validator].
Also, the [WP Plugin Handbook][wp-handbook] says that:
> If your plugin has no custom install settings, it's
> okay to omit this section.
[validator]: https://wpreadme.com/
[wp-handbook]: https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/#installation
* docs: update links, versions, add extra changelog items
* docs: lower version to stable ver
<opinion>
Explicit enumeration makes sense in legal documents, but CoCs are
more aspirational so I don't think it makes sense in this context.
You will end up either having to constantly add new things to the
list, or declare that the list is non-exhaustive (in which there's
not much point in enumerating in the first place).
This is doubly true given the inherently woolly realm of appropriate
interpersonal interactions that a CoC is implemented to moderate.
Also, remember the KISS principle. Personally, I think this is the
pinnacle of CoC design: https://github.com/karlgroves/dontbeadick
However, I'm sure there is a slightly-more-professional middle
ground ;)
</opinion>
I had to use some RegEx-fu for this. Specifically:
```bash
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/\(p\|l\|a\)_\(str\|bool\|int\|obj\|flo\|arr\)_//g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/MCI_Footnotes/Footnotes/g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/C_\(INT\|STR\|FLO\)_//g' {} \;
```
This should have covered all the bases.
In my testing I encountered one error caused by these changes.
In the `add_select_box` function in `/class/dashboard/layout.php`,
there was a function parameter called `$p_arr_options` and a variable
called `$l_str_options`. Removing the Hungarian notation caused an
error as these two variables were both now called `$options`.
This has been fixed, and I like to think that that will have been
the only naming conflict, but I think it is more likely that there
maybe others. Further testing is required before I am happy calling
this release-ready.
Close#34, progress #36
