Concerns around grouping package libraries by name

The [package libraries](https://github.com/dart-lang/language/blob/master/working/packaged-libraries/feature-specification.md) proposal says:

```
As the name implies, this is a group of mutually dependent libraries that are allowed to import
(or export) each other freely. A library can specify the name of the group it belongs to using a
library directive with an in clause:
```

This approach means that there is no _direct_ connection between the files that comprise a library group. If you are looking at a single file, which has a `library in` directive, how do you know what the other libraries are that are in that group? You would probably end up just searching all files in your package for that text, which works, but is far less than ideal. Or you could say its the job of the analyzer to figure out something sensible for the user, but that leaves behind anybody not using an editor with analyzer integration, and it probably requires specialized work in each editor plugin.

This sounds a bit like how parts _used_ to work, and we moved away from using names in that case for some of the same reasons (plus some others). I would actually argue that this issue was _less_ pronounced for parts, because at least if you could find the _root_ library, you could see all the parts. That would not be the case here, because there is no "root" library.

## Alternative proposal

One alternative could be to add a modifier on import/export directives instead. Lets say it is the `group` modifier (I hate that name but we can bikeshed later), so you get something like `group import 'a.dart';` or maybe `import group 'a.dart';`. This modifier would be _required_ for any import or export which creates an import cycle.

### Advantages

- Easy to provide an auto-fix in the analyzer, and easy to explain to users how to fix it in regular analysis output.
- Direct connection to all the other libraries in the group (although you can't see a holistic view from any given file, you may have to follow an import graph).
- Doesn't bring back the `library` directive that we have worked to make obsolete.
- Allows for custom lints like `don't use group imports where not necessary` to help users clean up their codebase if they want to only use this feature to handle cycles.

### Disadvantages

- You need to put a special modifier on each import that is a part of a cycle (imo this is also an advantage though).