Modify the coalescing of subtracks by taking into account the subindices
of the subtracks for deciding if they represent "logical" tracks
(merging them into one single track, as previously) or if they represent
physical tracks (treating them as individual tracks).
Add unit tests for nested logical/physical subtracks, and disc titles.
This is the payoff from the earlier refactorings: the control flow is now
consistent and clear, and the two factors (time vs. number, equal-chance or
not) are orthogonal. See also #2322.
Previously "pretend" mode (a.k.a. dry run mode) passed the command to be
printed directly to _log.info, whose first argument is technically a
format string. Thus the command string was parsed for replacement fields, such
as '{foo}', which could cause the format evaluation to fail if the filenames
contained in the command contained valid (or partially valid) replacement fields.
This fix simply inserts an argument '{0}' to the call to _log.info, which is a
format string that simply evaluates to the second argument to _log.info (the
command string). By doing this, the command string is not parsed for replacement
fields.
Discog plugin overrides the global logging for `requests` for a reason
that seems no longer valid.
I can't seem to reproduce the logging behavior mentioned in the
preceding comment, so I'm removing it.
If we do want to modify `requests` logging in the future, then we should
hook it into beets verbose logging.
* Readability and consistency
* Better logging: warn by default for attributes that were not found,
but don't drown user with info when everything is going well.
* I don't see DefaultList be really helpful in many other cases, so having
a beets.util.collections module (which could also conflict with the collections
module from standard library) with only that in it is a little silly.
* It was elegant and concise, but there are implementation issues: it is not
recommended to subclass builtin types, but the alternatives differ between python
2 and 3 (subclass sequence or container or collections.abc?), moreover,
interpreters can differ in the way they map syntaxic sugar to magic functions.
* Also, slicing and negative indexing could do weird things, so the class wouldn't
be really intuitive and simple at the same time
