Module <-> library equivalence

## Abstract

I am building a general purpose smart contract library called Compose. @cameel suggested I use free functions instead of Solidity libraries for my particular use case. I think that is a great idea so I refactored Compose to use modules/free files and it works great but there are some small issues I'd appreciate being fixed or clarified.

I'm going to call files that do not generate their own bytecode and that are not meant to be deployed "modules" in this issue. They contain definitions of things that are defined outside any contract or Solidity library.

1. In a Solidity library I can access `address(this)` and in a free file/module I cannot. I would like to access `address(this)` in a module, or in free functions. Rationale: the whole purpose of the free functions I use is to import them and use them in contracts, so it makes sense to give them direct access to `address(this)`, without dipping into assembly.

2. I cannot import a Solidity module and emit an event directly from it. Issue about that here: https://github.com/argotorg/solidity/issues/16314 Note that I can import a Solidity library and emit an event directly from it, but I am trying to replace Solidity libraries.

3. Improved NatSpec documentation for modules. I currently cannot write a NatSpec comment for a constant defined in a module. I can't write a NatSpec comment at the top of the module to document the module itself.

For example I would like to write the following NatSpec comment at the top of the module to document the module:

```Solidity
/**
* @title Diamond Module
* @notice Internal functions and storage for diamond proxy functionality.
* @dev Implements EIP-2535 Diamond Standard
* (https://eips.ethereum.org/EIPS/eip-2535)
*/
```

## Motivation

## Specification

## Backwards Compatibility

Start by reading the linked issue 16314 and separate the three requested module/library behaviors: address(this), direct event emission, and NatSpec support. The issue names no implementation files or tests, so first establish the relevant compiler entry points and expected language semantics. Done requires an agreed specification and testable acceptance criteria for each behavior.

Written by the indexing model from the issue text.