FR Allow filtering by context / for tags to be defined in terms of other tags

Currently, tags have single values, we do not have hierarchical tags (see #2038) and some pattern matching is currently not ideal (see #1720 - though I haven't tested this much myself). (I am not sure that hierarchical tags are actually desirable, personally, but that is not the current issue...)

You can get around this to an extent by setting contexts which take a set of filters. This is nice, but currently, if you want to search for tasks matching some subset of tasks with regularity you have three choices:
1. manually create something with your interactive shell's aliasing or abbreviation features. Fish now allowing abbreviations to match depending on the rest of the arguments (and there is a zsh plugin for the same thing), this is quite easy to do and allows you to easily set up some abbreviation to match for a subset of tasks, however there is the obvious downside here that this is a shell-generic feature and not a taskwarrior one.
2. you can set a context, and then manually switch every time.
3. ẏou can write some hooks that parse task tags and set them in some UDA and then filter based on the contents of that UDA. I feel this is the most clunky and worst option.

(2) leads to a lot of unnecessary typing. This FR suggests adding a novel filter for contexts, so you can search tasks within contexts with a `context:` filter. This would also allow more powerful searching, as you would be able to combine context filters.

A secondary proposal, or an alternative way of handling this, would be to allow us to set arbitrary tags _explicitly_ as a combination of other tags/filters via a configuration file option. Something like `tag.foo=+bar +fee`. This would seem to encroach on the territory of contexts quite a bit, but as someone who really only uses contexts as 'saved searches' and not so much as 'I will only look at XYZ for the next 4 hours,' I have to confess I find this syntax more intuitive. This has the same benefits as the previous idea in terms of allowing more combinatory filtering.

If either of these are adopted there is a question about how contradictory nested filters should be resolved. Should you just receive `no matches`? Should some take priority in some way? Should there simply be an message detailing the contradiction. If there is such a message, I think it would be ideal that there be an interactive way to 'correct' the contradiction on the fly.