Remove automatic __init__.py generation (set incompatible_default_to_explicit_init_py to true)

[rickeylev]

The automatic generation of __init__.py files has been a source of odd, surprising, and incorrect behavior. e.g. it makes directories importable that shouldn't be importable. This is because it's logic is extremely simple: create an init.py file in every parent directory for a path that ends with .py or .so.

It's also expensive: it requires flattening the runfiles at analysis time.

Some of the venv site package work incidentally side-steps this because the way it creates symlinks "hides" some of the paths from the regular set of runfiles.

Addressing this is a bit more complicated because the incompatible_default_to_explicit_init_py lives in bazel, but the usage is in rules_python.

In any case, I think the todo list is:

1. Add a rules_python flag to replace incompatible_default_to_explicit_init_py
2. Disable the behavior by default
3. Remove the dead code paths

Users can use --flag_alias to map (1) to the bazel builtin flag.

This is the rules_python side of bazelbuild/bazel#7386

[brandonchinn178]

This also causes issues if you have a non-empty __init__.py file (e.g. at the root of your project for users to import everything from), as Bazel will just clear the file entirely

[asymingt]

Removing the automatic __init__.py would potentially also allow us to leverage namespaced package (PEP420) support in Python 3.3+ to stitch together a single module from parts generated by an aspect run over a collection of targets. This would be very useful for generating python bindings for IDLs, like proto files and ROS messages.