fix: Import Long types

[ffflorian]

Long is implicitly loaded as dependency. If that fails for some reason, Long will be undefined.

This PR makes sure that the types for Long are always in place.

[stephenplusplus]

@dcodeIO what do you think?

cc @JustinBeckwith

[ffflorian]

@dcodeIO @JustinBeckwith any update on this?

[glasser]

When one actually tries to release a version of this package (which hasn't happened since this PR was merged), one presumably runs npm run release which runs npm run types which uses pbts on this package itself to generate the index.d.ts that is checked into this repo.

This causes the import * as Long from 'long' line to end up in index.d.ts in the repo itself. But this repo's index.d.ts already has an explicit Long interface! So this ends up as an error.

I think the solution is to remove the "Any compatible Long instance" jsdoc block from src/util/minimal.js.

[dcodeIO]

While working on #1356 I noticed several problems with this as well, and I'm considering to revert the changes made in this PR there. The intended process of working with proper Longs is to import it in own code if it is available. The .d.tses refer to instances that can be either LongBits (long.js is not installed, just the basics) or Long (long.js is installed) as a common interface protobuf.Long anyway, so importing Long it into these should be a nop or in the worst case an error anyway.