Using a lightweight build backend

[Avasam]

See discussion full discussion started in #165 (review)

Looks like flit_core might be the best fit.

[srittau]

What are the advantages over using setuptools?

[hauntsaninja]

The advantages of using flit_core over setuptools are:

• Stronger track record of backward compatibility
  • Over the years I've been broken by setuptools many times, hatchling a few times, poetry once and flit never
• It's much, much smaller. It's nice for our build dependencies to be tiny
• Avasam benchmarked it as close to 2x faster

For the vast majority of our users this will not make a difference, since most users use wheels.

Just to spell out the one specific concern from #165 (review):

• setuptools makes a lot of breaking changes (they releases changes that we have to account for at work multiple times a year)
• Unlike normal dependencies, it's actually a little fiddly to pin build time dependencies because they work in isolated environments
• The only way to do this is PIP_CONSTRAINT. Unfortunately, that means there isn't really a way to say "only use this constraint on setuptools when building this package that setuptools has broken"
• So if we require recent setuptools versions in types-* packages, even if setuptools doesn't break us, users who build from sdists may find themselves in difficult positions because some package they use is broken by new setuptools and types-* packages require new setuptools

I have a few more thoughts on setuptools' health as a project, but don't really want to go into them too much. setuptools maintainers are in an unenviable position and it's been a hard week or two for them

[srittau]

The build tool we decide on should probably support *.data directories, see #171.