Commit order and rebasing

The main development branch will be regularly rebased to clean up the code, improve the commit messages and keep a sane commit order. Tags offer the stable history and releases will be very frequent to keep the diffs between tags to a minimum.

Changes will be split up and ordered in a way that reduces the dependencies between them as much as possible. If multiple features share infrastructure, that should be in a separate commit rather than added by the first feature using the infrastructure. If changes touch the same area of code, the features that are most feasible to upstream should be ordered first so that they're the ones that are easiest to extract and upstream first.

As much as possible will be landed upstream to reduce the maintenance burden. Landing code upstream frees up more time to work on downstream changes. The code review obtained while trying to upstream a change can be useful even if it doesn't land and it can result in other people making related security enhancements.

General order:

1. backports from torvalds/linux.git master
2. backports from other trees before they get into master
3. configuration changes (both Kconfig and default values in code without a config option)
   1. kernel self-protection options
   2. userspace hardening options
4. bug fixes
5. const
6. const-style __read_only usage
7. __ro_after_init
8. kernel self-protection features
9. userspace hardening features
   1. aslr improvements
   2. assorted other features