Make luajit2 into a fully supported project with releases

Given that the official repository for LuaJIT is now abandoned for almost a year, most people I know who are interested in the LuaJIT ecosystem are interested in seeing luajit2 become a first class project instead of a branch of LuaJIT.

To make this possible, the following goals need to be met:

1. Put the openresty extensions under an optional flag. I need to think about it more seriously and make suggestions/PRs in #63
2. Start development on the master branch
3. Start making release tarballs

Then there are secondary features that would be highly desirable for distributions:

1. Release branches (v2.1, v2.2, etc.)
2. Testsuite integrated into the main repository so that distributions can run make check in their %check targets for testing. I have PR #78 open for this.

Branches

To start development on the master branch, I propose the following:

1. Make a v2.0 branch that tracks the current master branch. This is where v2.0 fixes go in as needed
2. Keep the v2.1 branch as is and make a release tarball (2.1.0) for distributions to pick up
3. Merge v2.1 into master and then start putting all new patches into master going forward, making release branches and/or tarballs at a regular cadence, say, every 3 months.

Documentation

I propose that we convert the luajit HTML documentation into markdown so that it is convenient to read in github. We should also move the features mentioned in README.md into the main documentation and make README.md more about installation and development documentation.

Needless to say, I'm happy to help with one or more of these tasks. My intention is to propose a new package luajit2 to deprecate luajit in Fedora. That way I can add tarballs instead of having to host hundreds of patches.

Start by reviewing the proposed branch and release plan, the open PRs #63 and #78, and the current README.md and HTML documentation. Determine which goals are still relevant, including release tarballs, integrated tests, optional OpenResty extensions, and documentation changes; completion would require an agreed project plan rather than one isolated edit.