EthPM, Standard Libary, and Packages ... Oh My!

### What is wrong?

One of the *powerful* features of Python that I've often taken for granted is the standard library.

Similarly, packaging in general is something that isn't yet present in smart contract languages, and would be a compelling feature.

### How can it be fixed

EthPM exposes a few different kinds of assets.

1. Source Files
2. Compiled Contracts
3. Deployed Contracts

In *theory* Fe can support interfacing with all of these, though the source file level is probably the most questionable since that would ultimately require dealing with negotiation of types of source files and compatibility of source files with whatever version of the compiler is being used.

We would also need to hash out what the actual syntax is for these imports. How would someone cleanly reference deployments vs contract interfaces in import statements? Exploration into this will be needed.

#### Source Files

Interfacing with compatible source files would simply be a matter of establishing a standard for where the Fe-lang compiler will look when attempting to *import* from an installed package. Nick did some work in the EthPM CLI tool for doing local installs. I don't recall if it was ever strictly specified but there is an established directory structure it uses which would probably be the appropriate starting point for mapping `import` statements to source files that have been installed this way.

#### Compiled Contracts

Fe-lang should be able to work with previously compiled assets, assuming they come with an ABI. These can be used to construct a definition of an external interface to define how we can interact with them. One might *install* a standard ERC20-interface package in order to import it and be able to interact with ERC20 contracts in a generic manner, without needing to embed the interface into the local code.

#### Deployed Contracts

This is likely the most compelling and complicated feature, since deployments are chain specific, meaning that compilation would have to be done under some sort of *context* for the chain it's being compiled for. In this version, you could actually import contracts that include **both** the interface, and the actual address that the contract is deployed to. This functionality would be the foundation for both library code (aka the standard library) and for actually importing and interacting with specific contracts.

For the Library use case, there might be a `DateTimeLibrary` contract out there which maybe exposes `Date` and `DateTime` types. This gives Fe-lang enough information to enforce type safety and understand the various methods that the different types expose. At compile time Fe-lang would need to either do a *generic* compile which leaves the resulting bytecode unlinked, or to compile against a specific chain which would link the bytecode against the address of the deployed contract.

Start by reviewing the EthPM CLI's local-install directory structure and how Fe compiler import statements are currently handled. The work is complete when the syntax and behavior for importing source files, ABI-backed compiled contracts, and chain-specific deployed contracts are defined and documented.

Written by the indexing model from the issue text.