Initial commit for distribution package. Contains Exponential, Laplace, ...

...Normal, and Uniform
The more I look at it the less and less I am liking using slices to group distribution parameters together in an arbitrary order, unless absolutely needed (such as an arbitrary discrete CDF, arbitrary continuous CDF, etc). My reasons are:
* Code clarity is severely hampered and therefore more prone to errors due to arbitrary and different indexing orders of numbers with different meaning
* Code discovery is hampered as the function signature is not detailed enough to describe what is being done (there are any side effects), and the signature says nothing about what is contained in the slices. The user must go visit the documentation for every new call.
* Side effects exist for such a simple call: the possible allocation of a slice and a possible panic. This to me could be unpleasantly surprising to a user, as the fundamental action of getting a distribution's parameters could cause their entire program to unwind! Surprising users in bad ways is something I'd like to avoid as much as possible in an API.

I realize the abstraction use cases can be very useful, as Brendan mentioned with FitPrior. However, since FitPrior *modifies the distribution* directly, I see no reason why it needs to:
* Return the distribution parameters (There's already a function that does that: *Parameters*)
* Return the distribution parameters *in a slice* (FitPrior could just use the distribution's existing parameters as the previous *priorValue*)

The only thing that truly seems distribution-dependent is the *priorWeight*, which can be hidden behind an interface with no exported functions to keep the algorithms abstract and to prevent the user from inadvertently messing with it ([See my example here](https://github.com/cjslep/goExportTest)). This way the client can use the abstract algorithm as before and just uses the generalized interface calls to FitPrior by handing over some HiddenInterfaceType all the while they cannot modify the HiddenInterfaceType (and shooting themselves in the foot). We can then pull the slice back out within FitPrior and modify the distribution within FitPrior. Since FitPrior will no longer need to return the distribution parameters, the parameter-getting and parameter-setting can be distribution-specific multi-return and multi-argument functions, respectively. This then keeps those functions short, discoverable, and side-effect free.

A very rough code sketch of above paragraph:
```go
type Prior interface {
     values() []float64 // hidden from user
}

type priorWeights []float64
func (p priorWeights) values() []float64 {
     return p
}

func (n *Normal) FitPrior(samples []float64, weights []float64, priorWeight Prior) (newPriorWeight Prior) {
     // Do nil check on priorWeights, take correct behavior on no priors...
     priorWeights := priorWeight.values()
     // Do length check and such same as before...
     n.Mu = ___ // Client no longer needs slice return from Parameters getter
     n.Sigma = ___ // Client no longer needs slice return from Parameters getter
     return Prior([]float64{___, ___}) // User no longer has access to slice
}

func (n Normal) Parameters() (mu float64, sigma float64) {
     mu := n.Mu
     sigma := n.Sigma
     return
}

func (n *Normal) SetParameters(mu, sigma float64) {
     // etc
}
```