Add Mechanism/Workflow for keeping track of backports

I think we have this covered now. @Jan-Simon Moeller @Martin Kelly Please comment. 

Yes. I think once we have this, we may also want some common backports that apply to all layers.

On more comment from my side ...
If we take the profiles into account. Basically we'll end-up with a 'meta-backports' or 'backports' in each profile (as they need to be independent of each-other).

@Stephane Desneux yes, you are right, I forgot one level of directory structure, thanks for catching it. Please let me know if there's something else I missed. I updated the PR to fix this.

Here's how the structure looks now. My main concern is that it's a bit verbose (many levels of depth). I don't see an easy way to improve on that without sacrificing something important, but let me know if you think of something.

martin@columbia:~/layer-reorg/src/AGL/new/meta-agl-core-base$ tree meta-backports
meta-backports
├── meta-openembedded
│   └── recipes-support
│       └── open-vm-tools
│           └── new-recipe
│               ├── backport.yml
│               ├── files
│               │   ├── tools.conf
│               │   └── vmtoolsd.service
│               ├── open-vm-tools
│               │   ├── 0001-configure.ac-don-t-use-dnet-config.patch
│               │   └── 0002-add-include-sys-sysmacros.h.patch
│               └── open-vm-tools_10.1.5.bb
└── meta-qt5
    └── recipes-qt5
        └── qt5
            └── qtbase-native
                └── qdbuscpp2xml-segfault
                    ├── backport.yaml
                    └── qtbase-native_git.bbappend

11 directories, 8 files

Seems good:

I re-read the thread on the mailiing list and from what I see in latest comments, it's close to something satisfying.

Having the README.backport for details + a "reason" in the path ("feature-1", "feature-2"," bugfix-1" in the example above) gives the opportunity to quickly specify what/src/dest/why: it's a bit like my initial draft (iteration 4 here) but it's more simple and provides more freedom than strict naming with 'backport-origin-dest" or "pinning-origin". It also follows Tanikawa's observation: keeping things simple makes sense.

We have a good compromise here: even if an extra subfolder adds a little complexity, I think it's still easier than reading a README to catch the idea behind a backport.

@Martin Kelly: your PR on github doesn't follow the latest scheme, right ? Or did I miss something during vacation ?