core, frontends: avatar refactoring: /!\ huge commit Avatar logic has been reworked around the IDENTITY plugin: plugins able to handle avatar or other identity related metadata (like nicknames) register to IDENTITY plugin in the same way as for other features like download/upload. Once registered, IDENTITY plugin will call them when suitable in order of priority, and handle caching. Methods to manage those metadata from frontend now use serialised data. For now `avatar` and `nicknames` are handled: - `avatar` is now a dict with `path` + metadata like `media_type`, instead of just a string path - `nicknames` is now a list of nicknames in order of priority. This list is never empty, and `nicknames[0]` should be the preferred nickname to use by frontends in most cases. In addition to contact specified nicknames, user set nickname (the one set in roster) is used in priority when available. Among the side changes done with this commit, there are: - a new `contactGet` bridge method to get roster metadata for a single contact - SatPresenceProtocol.send returns a Deferred to check when it has actually been sent - memory's methods to handle entities data now use `client` as first argument - metadata filter can be specified with `getIdentity` - `getAvatar` and `setAvatar` are now part of the IDENTITY plugin instead of XEP-0054 (and there signature has changed) - `isRoom` and `getBareOrFull` are now part of XEP-0045 plugin - jp avatar/get command uses `xdg-open` first when available for `--show` flag - `--no-cache` has been added to jp avatar/get and identity/get - jp identity/set has been simplified, explicit options (`--nickname` only for now) are used instead of `--field`. `--field` may come back in the future if necessary for extra data. - QuickContactList `SetContact` now handle None as a value, and doesn't use it to delete the metadata anymore - improved cache handling for `metadata` and `nicknames` in quick frontend - new `default` argument in QuickContactList `getCache`

d660d1e5cee410bf9ac15b89ceb93543bcff0a6f 0.0.2
b95550704b4f965c9dca5f6681186bf8a9b64074 0.0.3
b778622b87337785252d47d2b3c4fe3085a37ab4 0.1.0
53aa958a2d3d6451ae75610e3c6fb947d3d6f21b 0.1.1
cc2afb92ab93a4c6399ca9b6cdc5224878a57a24 0.2.0
df6b9b881f0e9f335483c986b00fd58f2ed6164a 0.3.0
12cfa23c6ab9235dddb2e8887eb0fe90fc98da75 0.4.0
f93e917be3f41a254a4612da22ed9fc5e0209f80 0.4.1
a090e5ee83c2c2d9d110c7516c3d74573426a97b 0.5.0
008c8ccd5dcc4c47578ee7190e6823186720c864 0.5.1
21e6d11615eaeb7e03bacf4eb53e5c3c5d54ce08 0.6.0
b075c5a576ef3ce628e30b0ce02bf00ec35a3c4c 0.6.1
eecd84a2530aacb3255f702cdab2010b39bb1851 0.7.0a1
eecd84a2530aacb3255f702cdab2010b39bb1851 0.7.0a1
0000000000000000000000000000000000000000 0.7.0a1
0000000000000000000000000000000000000000 0.7.0a1
534b264d63df0e6241395b26cfd994b9fee187f0 0.7.0a1
b42aa52d262106ee6743d0205830be9d837ebfa9 0.7.0a2
7d2d28564b3e8c540e7dfc38f0742cbd440f9013 0.7.0a3
1798d4ace296a95fa4081b2e84fa6c97b60a22e3 0.7.0a4
c6464685fcbbb368823919affca3fc16cb3c83c4 0.7.0b1
43e5e0dc8c609cbd1d814043a384a72bef16e55e 0.7.0b2
dbf24ba40396ec3f517f8f7855531d24d0ee701f 0.7.0b3
86bfdf73d24a7a1b7f56abdf5ca51552c6e41101 0.7.0b4
c7138e9132138f79ba66b0d65c45d45399f55a2b 0.7.0