Some Gradle experts at $WORK have told me that the way we were
previously resolving artifacts wasn't strictly correct due to two reason:

- Project references in project configurations (like the ones we resolve
  in `getConfigurationArtifacts`) are allowed to be empty for now, but
  that will change, and it's a bug. gradle/gradle#26155

- The way we currently resolve artifacts doesn't let Gradle know our
  intention (as we can resolve any arbitrary configuration) and it
  doesn't play well with Gradle transforms, which require all of the
  resolved configuration artifacts to be present, otherwise it fails
  with a `FileNotFoundException`.

As a result, I changed the code to introduce a Gradle configuration
`bloopConfig` that extends all those configurations we care about, and
change the resolution code to only depend on that configuration.

It seems that solution works and passes all tests, and it avoids the
`FileNotFoundException` error I found out.

Because we now have a proper `configuration`, it means that users that
create their own configuration and want it to be exported to bloop need
to do `bloopConfig.extendsFrom(myConfig)` where `myConfig` is a
user-defined configuration. The reason for this is because when we
declare that our configuration extends all the other existing
configuration, we do it at evaluation time. User-defined configurations
run after the bloop plugin, so they never get added unless the user
wishes to. This is not a big deal as custom configuration are extremely
rare, and this is a common practice in Gradle land when you define your
own configuration.

The previous solution worked, but it was not ideal because it introduced
the concept of a `bloopConfig` that had to extend all the configurations
in the project (even across different source sets, e.g. main, test,
integTest, etc.).

This is awkward because the plugin generates a bloop config per source
set. So, if we have one bloop config extending all configurations from
all source sets, and then depending on that when generating bloop config
per source set, we're running into a lot of repeated resolutions to
produce the necessary artifacts and the resolution config section
contains a lot more artifacts than it should (e.g. foo.json and
foo-test.json would contain the same set of artifacts). Also, in theory,
this approach could also cause Gradle to add the wrong artifact version
because it would need reconciling all artifact across all source sets
is more likely to produce different results. This is a theoretical
point, but it'd be nice to avoid it.

So, the fix to all of this is to make a `bloopConfig` configuration per
source set. For example, the main source set gets a `bloopConfigMain`
configuration that extends from some default configurations that we care
about for Java/Scala plugins.

(In the Android world, there are no sourcesets, but "variants" so we
fallback on the previous behavior and depend on all the sources for
`bloopConfigAndroid`, a config that exists only in Android projects and
that adds the artifacts of all the project variants -- this is the
behavior one expects, and in this case we extend from all the
configurations in the variants for backwards compatibility.)

To make the process more customizable for end users, I've also added a
new property in the bloop configuration that lets users specify the
extra configurations that should be extended per source set:

```
bloop {
  extendUserConfigurations = [configurations.myCustomConfig.name]
}
```

This way, users have control over the configurations that should also
contribute artifacts to the resolution section in the bloop config.
This is nice and better than the previous approach.